[GHC] #9929: New alias handling not compatible with LLVM 3.4

[GHC]

#9929: New alias handling not compatible with LLVM 3.4
-------------------------------------+-------------------------------------
        Reporter:  rwbarton          |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  high              |               Milestone:  7.10.2
       Component:  Compiler (LLVM)   |                 Version:  7.10.1-rc1
      Resolution:                    |                Keywords:
Operating System:  Linux             |            Architecture:  x86_64
 Type of failure:  Compile-time      |  (amd64)
  crash                              |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------
Changes (by rwbarton):

 * status:  closed => new
 * resolution:  worksforme =>


Old description:

> 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...?

New description:

 '''Edit''': we're going to leave GHC 7.10 broken with LLVM 3.4 as
 described below, but then we should at least update GHC's information
 about which versions of LLVM it can use.

 ----

 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...?

--

Comment:

 We should also add a warning telling people to use LLVM 3.5 since we know
 that that is the version that we need. (I actually thought the existing
 warning for a too old LLVM version would trigger, but it doesn't.) I've
 already seen at least one person confused about this thinking that 7.10
 has no support for LLVM at all.

 I'll repurpose this ticket to track that.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9929#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler