[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