[GHC] #9929: New alias handling not compatible with LLVM 3.4
GHC
ghc-devs at haskell.org
Fri Dec 26 19:12:32 UTC 2014
#9929: New alias handling not compatible with LLVM 3.4
-------------------------------------+-------------------------------------
Reporter: rwbarton | Owner:
Type: bug | Status: new
Priority: high | Milestone: 7.10.1
Component: Compiler (LLVM) | Version: 7.10.1-rc1
Keywords: | Operating System: Linux
Architecture: x86_64 (amd64) | Type of failure: Compile-
Difficulty: Unknown | time crash
Blocked By: | Test Case:
Related Tickets: | Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
As reported by Joachim here: https://www.haskell.org/pipermail/ghc-
devs/2014-November/007480.html, and it happens for me too. It seems to
affect every program compiled with `-fllvm`; T5681 just happens to be the
only such program in the normal test suite.
Faced with the definitions
{{{
@Main_zdwwork_info_itable$def = internal constant
%Main_zdwwork_entry_struct<{
i64 add (i64 sub (i64 ptrtoint (i8* @S2ZH_srt to i64),i64 ptrtoint (
void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)*
@Main_zdwwork_info$def to i64)),i64 8),
i64 4294967299, i64 0, i64 4294967311}>,
section "X98A__STRIP,__me3", align 8
@Main_zdwwork_info_itable = alias i8* bitcast
(%Main_zdwwork_entry_struct* @Main_zdwwork_info_itable$def to i8*)
}}}
LLVM 3.4 produced the assembly
{{{
.type Main_zdwwork_info_itable, at object #
@Main_zdwwork_info_itable
.section .rodata,"a", at progbits ; note .rodata, not
X98A__STRIP,__me3!
.globl Main_zdwwork_info_itable
.align 16
Main_zdwwork_info_itable:
.quad (S2ZH_srt$def-Main_zdwwork_info$def)+8
.quad 4294967299 # 0x100000003
.quad 0 # 0x0
.quad 4294967311 # 0x10000000f
.size Main_zdwwork_info_itable, 32
}}}
At first I thought this was an LLVM bug, but after reading
http://llvm.org/docs/LangRef.html#linkage-types I'm not sure; maybe the
`internal` linkage type means that `@Main_zdwwork_info_itable$def` is just
a constant value without any "identity", so the LLVM optimizer is free to
drop it, merge it with another constant, or move it to another section?
One workaround would be to use external linkage for these
`foo_info_itable$def` symbols, and then if desired (to reduce symbol table
size), strip out any `.global bar$def` statements in the LLVM mangler...?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9929>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list