[GHC] #9929: New alias handling not compatible with LLVM 3.4
#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,@object # @Main_zdwwork_info_itable .section .rodata,"a",@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
#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 | Version: 7.10.1-rc1 (LLVM) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): A small test case for LLVM's behavior here: {{{ ; test.ll @foo$def = internal constant i64 123, section ".mysection" @foo = alias i8* bitcast (i64* @foo$def to i8*) $ opt-3.4 -O1 test.ll -o test.lo && llc-3.4 test.lo -o test.s && cat test.s }}} LLVM 3.3 and 3.4 both put `foo` in the `.rodata` section, while 3.5 puts it in `.mysection`. (So perhaps this behavior was considered to be a bug, and fixed in 3.5.) For some reason, GHC's usage of LLVM 3.3 is okay nevertheless (this isn't the way that GHC invokes opt/llc and my guess is that the difference is due to different optimizations enabled by default in LLVM 3.3). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9929#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 | Version: 7.10.1-rc1 (LLVM) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: bgamari (added) Comment: Actually, would it be possible to skip the whole `$def` game for info tables? We never need to refer to an `_info_itable` symbol from another module, right? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9929#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 | Version: 7.10.1-rc1 (LLVM) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9929#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): From the link at the start of the crash it seems that the compile error is: Error: can't resolve `.rodata' ... Just wanted to add this so people can easily know if they are encountering this error. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9929#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 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 George): * cc: george (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9929#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): Workaround is to use llvm 3.5 correct? If so, should the priority be high? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9929#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by altaic): FYI, I pinged the LLVM guys for clarification-- http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/083754.html -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9929#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler (LLVM) | Version: 7.10.1-rc1 Resolution: worksforme | 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 thoughtpolice): * status: new => closed * resolution: => worksforme Comment: Yes, so I think for this one the answer simply is: 7.10 only supports LLVM 3.5. 7.12 will support LLVM 3.6 exclusively. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9929#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler (LLVM) | Version: 7.10.1-rc1 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): Agreed. However this needs to be documented as the GHC 7.10.1 User's Guide is not correct with respect to this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9929#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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,@object # @Main_zdwwork_info_itable .section .rodata,"a",@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,@object # @Main_zdwwork_info_itable .section .rodata,"a",@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
#9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | thoughtpolice Priority: high | Status: new Component: Compiler (LLVM) | Milestone: 7.10.2 Resolution: | Version: 7.10.1-rc1 Operating System: Linux | Keywords: Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice Comment: Right, I'll take care of docs and a ticket. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9929#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | thoughtpolice Priority: high | Status: new Component: Compiler (LLVM) | Milestone: 7.10.2 Resolution: | Version: 7.10.1-rc1 Operating System: Linux | Keywords: Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): #10302 is a doc ticket that tells people to use llvm 3.5. Do we want to close this and just track 10302? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9929#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | thoughtpolice Priority: high | Status: closed Component: Compiler (LLVM) | Milestone: 7.10.2 Resolution: fixed | Version: 7.10.1-rc1 Operating System: Linux | Keywords: Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => fixed Comment: The configure script in both the `master` branch and the `ghc-7.10` branch now explicitly check that the llvm tools are the right versions for the respective branches. Closing this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9929#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC