performance regressions

[Ben Gamari]

Joachim Breitner <nomeata at debian.org> writes:

> Hi,
>
> Am Montag, den 15.12.2014, 10:58 -0500 schrieb Ben Gamari:
>> >> - Travis has not picked up on these errors.
>> >
>> > unfortunately, travis is slighly less useful since a few weeks due to
>> > T5681 failing (possibly due to the use of LLVM-3.4), but I’m still
>> > waiting for an reply on that issue.
>> >
>> You aren't looking for a response from me on this, are you? I just
>> checked and I don't seem to have any outstanding messages from you but
>> it's entirely possible I overlooked something.
>
> this is independent of our arm issues, and I think a tad older; I did
> not direct it to anyone specific.
>
> But I guess you are likely a person that can tell what’s wrong here:
>
> Am Sonntag, den 30.11.2014, 20:01 +0100 schrieb Joachim Breitner:
>> Compile failed (status 256) errors were:
>> /tmp/ghc16123_0/ghc16123_5.s: Assembler messages:
>> 
>> /tmp/ghc16123_0/ghc16123_5.s:26:0:
>>      Error: can't resolve `.rodata' {.rodata section} - `Main_zdwwork_info$def' {.text section}
>> 
>> /tmp/ghc16123_0/ghc16123_5.s:46:0:
>>      Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def' {.text section}
>> 
>> /tmp/ghc16123_0/ghc16123_5.s:66:0:
>>      Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def' {.text section}
>> 
>> /tmp/ghc16123_0/ghc16123_5.s:86:0:
>>      Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def' {.text section}
>> 
>> /tmp/ghc16123_0/ghc16123_5.s:106:0:
>>      Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def' {.text section}
>> 
>> /tmp/ghc16123_0/ghc16123_5.s:126:0:
>>      Error: can't resolve `.rodata' {.rodata section} - `ZCMain_main_info$def' {.text section}
>> 
>> *** unexpected failure for T5681(optllvm)
>> 
>> https://s3.amazonaws.com/archive.travis-ci.org/jobs/42557559/log.txt
>> 
>> Any ideas?
>
> Is it possible that this is due the llvm version used? Do we support 3.4
> in GHC HEAD?
>
>    Using LLVM tools
>       llc   : /usr/local/clang-3.4/bin/llc
>       opt   : /usr/local/clang-3.4/bin/opt
>
> (http://smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm-backend.html
> does not talk about GHC HEAD explicitly. Should I look at the 7.10
> row? Does that mean that 3.4 is not supported? Shouldn’t the build
> system, or at least the compiler, fail harder and more helpfully in
> this case?)
>
LLVM 3.4 appears to have an unfortunate behavior whereby it will lose track
of which section symbols with Internal linkage belong.  I haven't had a
chance to delve into this too deeply, however given that both 3.3 and
3.5 behave as expected I'm pretty sure this a bug. There are a few
options here,

  a. Mark the `$def` symbols as ExternallyVisible, working around the
  issue at the expense of exposing internal symbols to the outside
  world.

  b. Mark LLVM 3.4 as unsupported

At the moment I'm leaning towards (b) since I haven't had a chance to
think through the implications of (a); if nothing else I suspect this
wouldn't help the DLL symbol table size issues on Windows. Giving up on
LLVM 3.4 might be unfortunate for a good number of users, however.

Ultimately this underlines the need to package LLVM with GHC.

Cheers,

- Ben


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141215/521a8ac9/attachment.sig>