LLVM backend broken with LLVM 2.9

[tener]

Even simplest programs like

module Main where
main = return ()

Fail when compiled with -fllvm

The error is:

ghc -fllvm --make llvm.hs
[1 of 1] Compiling Main             ( llvm.hs, llvm.o )
/tmp/ghc3024_0/ghc3024_0.s: Assembler messages:

/tmp/ghc3024_0/ghc3024_0.s:175:0:
     Error: can't resolve `Main_main_srt' {.rodata section} - `Main_main_info' {.text; .text 6# section}

/tmp/ghc3024_0/ghc3024_0.s:185:0:
     Error: can't resolve `ZCMain_main_srt' {.rodata section} - `ZCMain_main_info' {.text; .text 12# section}

[tener]

Additional info:

llvmc --version
Low Level Virtual Machine (http://llvm.org/):
  llvm version 2.9
  Optimized build.
  Built Apr  7 2011 (11:28:04).
  Host: x86_64-unknown-linux-gnu
  Host CPU: corei7

  Registered Targets:
    (none)

uname -a
Linux raptor 2.6.37-ARCH #1 SMP PREEMPT Fri Mar 25 15:10:00 CET 2011 x86_64 Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz GenuineIntel GNU/Linux

The Linux distro is Arch Linux.

[dterei]

Yeah this is a known issue. On Mac OS X things should work but on Linux and Windows LLVM has changed how section labels are handled and so this is the problem.

A work around is this. Put the attached script on your path before the system 'as' program so it runs instead. Basically the script runs sed over the assembly to fix up the labels before running 'as' as usual.

Otherwise you'll have to wait for the next GHC release. LLVM 2.9 works fine otherwise. I actually helped fix 2 fairly major bugs in the RC's to make sure of this.

[tener]

Replying to dterei:

Yeah this is a known issue. On Mac OS X things should work but on Linux and Windows LLVM has changed how section labels are handled and so this is the problem. A work around is this. Put the attached script on your path before the system 'as' program so it runs instead. Basically the script runs sed over the assembly to fix up the labels before running 'as' as usual. Otherwise you'll have to wait for the next GHC release. LLVM 2.9 works fine otherwise. I actually helped fix 2 fairly major bugs in the RC's to make sure of this.

Do you mean that GHC HEAD should work fine? I tried but it failed with the same error.

Also the script you provided doesn't solve the issue, unfortunately: - $4 should be renamed to $5, at least on x86_64 - the errors are still the same

Perhaps on 64 bit platform labels have different handling still?

[tener]

I found a problem: sed patter uses space, whereas in .s files found on my machine \t are used. After this fix everything is fine.

$5 is needed because of extra --64 flag passed to the "as"

[dterei]

hehe, yeah the 'fix' is a little temperamental but you seem to have figured it out.

[daniel.is.fischer]

Also broken with llvm-3.0 (the package is llvm-2.9.99, so alpha or beta, on openSuSE 11.3),

$ llc --version
Low Level Virtual Machine (http://llvm.org/):
  llvm version 3.0
  Optimized build with assertions.
  Built Apr  9 2011 (14:36:06).
  Host: i386-pc-linux-gnu
  Host CPU: nocona

  Registered Targets:
    alpha   - Alpha [experimental]
    arm     - ARM
    bfin    - Analog Devices Blackfin [experimental]
    c       - C backend
    cellspu - STI CBEA Cell SPU [experimental]
    cpp     - C++ backend
    mblaze  - MBlaze
    mips    - Mips
    mipsel  - Mipsel
    msp430  - MSP430 [experimental]
    ppc32   - PowerPC 32
    ppc64   - PowerPC 64
    ptx     - PTX
    sparc   - Sparc
    sparcv9 - Sparc V9
    systemz - SystemZ
    thumb   - Thumb
    x86     - 32-bit X86: Pentium-Pro and above
    x86-64  - 64-bit X86: EM64T and AMD64
    xcore   - XCore
$ opt --version
Low Level Virtual Machine (http://llvm.org/):
  llvm version 3.0
  Optimized build with assertions.
  Built Apr  9 2011 (14:36:06).
  Host: i386-pc-linux-gnu
  Host CPU: nocona

  Registered Targets:
    (none)

Putting the above as script in ~/bin doesn't help, since no as is called:

Running phase LlvmOpt
*** LLVM Optimiser:
opt /tmp/ghc9231_0/ghc9231_0.ll -o /tmp/ghc9231_0/ghc9231_0.bc -O1
Running phase LlvmLlc
*** LLVM Compiler:
llc -O2 -relocation-model=static /tmp/ghc9231_0/ghc9231_0.bc -o /tmp/ghc9231_0/ghc9231_0.s
Running phase As
*** Assembler:
/usr/bin/gcc -I. -c /tmp/ghc9231_0/ghc9231_0.s -o nothing.o -fno-stack-protector -DDONT_WANT_WIN32_DLL_SUPPORT
/tmp/ghc9231_0/ghc9231_0.s: Assembler messages:

/tmp/ghc9231_0/ghc9231_0.s:185:0:
     Error: can't resolve `Main_main2_srt' {.rodata section} - `Main_main2_info' {.text; .text 10# section}

/tmp/ghc9231_0/ghc9231_0.s:206:0:
     Error: can't resolve `ZCMain_main_srt' {.rodata section} - `ZCMain_main_info' {.text; .text 20# section}

[dterei]

I don't put any effort into support pre-released versions of LLVM sorry. So your on your own there, however the error is the same error as with 2.9, so the 'as' hack should work. Its a very hacky hack though so you probably need to modify it for your particular machine as tener in the comments above.

[dons]

I needed to tweak the regex to include tabs,

sed 's/.section[    ]*\".text\; .text/.section        .text\; .text/' "$4" > "$4.fixed_s"

[Blaisorblade]

FYI, after being hit by this bug on a new installation (GHC 7.0.3/Linux/64bit/bindist), I added a mention of this bug in the installation instruction:  http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Installing

[dterei]

Fixed. 50e0db459cb1b1341bbd527a3c450f0930e6ab43