Opened 3 years ago

Closed 3 years ago

#9929 closed bug (fixed)

New alias handling not compatible with LLVM 3.4

Reported by: rwbarton Owned by: thoughtpolice
Priority: high Milestone: 7.10.2
Component: Compiler (LLVM) Version: 7.10.1-rc1
Keywords: Cc: bgamari, erikd, george
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by rwbarton)

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

Change History (14)

comment:1 Changed 3 years ago 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).

comment:2 Changed 3 years ago by rwbarton

Cc: bgamari added

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?

comment:3 Changed 3 years ago by erikd

Cc: erikd added

comment:4 Changed 3 years ago 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.

comment:5 Changed 3 years ago by George

Cc: george added

comment:6 Changed 3 years ago by George

Workaround is to use llvm 3.5 correct? If so, should the priority be high? Should the milestone be 7.10.1?

Last edited 3 years ago by George (previous) (diff)

comment:7 Changed 3 years ago by altaic

FYI, I pinged the LLVM guys for clarification-- http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/083754.html

comment:8 Changed 3 years ago by thoughtpolice

Milestone: 7.10.17.10.2

Moving to GHC 7.10.2.

comment:9 Changed 3 years ago by thoughtpolice

Resolution: worksforme
Status: newclosed

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.

comment:10 Changed 3 years ago 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. Filed documentation ticket #10302 for this

Last edited 3 years ago by George (previous) (diff)

comment:11 Changed 3 years ago by rwbarton

Description: modified (diff)
Resolution: worksforme
Status: closednew

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.

comment:12 Changed 3 years ago by thoughtpolice

Owner: set to thoughtpolice

Right, I'll take care of docs and a ticket.

comment:13 Changed 3 years ago 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?

comment:14 Changed 3 years ago by erikd

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.