optllvm failures

I have done a bit of testing with regards to my optllvm failures in the testsuite. Some tests compile but segfault when they are run, others fail to compile, both with HEAD and 7.8.2, but those I tested all work with 7.6.3, although 7.6 gives the warning: You are using a new version of LLVM that hasn't been tested yet! We will try though... I suspect that the LLVM backend thinks I have a different version than I actually have, or maybe the LLVM tools think I have a different CPU than I have: dafis@schwartz:~/JNthPrime> llc --version LLVM (http://llvm.org/): LLVM version 3.2svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx Registered Targets: arm - ARM ppc32 - PowerPC 32 ppc64 - PowerPC 64 thumb - Thumb x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 dafis@schwartz:~/JNthPrime> opt --version LLVM (http://llvm.org/): LLVM version 3.2svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx But my CPU is a Core i5, not i7. Can somebody confirm or deny that that may be the cause?

What OS? Is this on a vm? I7-avx is the instruction family. I5 will be ok. Certain vms break handling avx register saves. On Thursday, April 24, 2014, Daniel Fischer < daniel.is.fischer@googlemail.com> wrote:
I have done a bit of testing with regards to my optllvm failures in the testsuite.
Some tests compile but segfault when they are run, others fail to compile, both with HEAD and 7.8.2, but those I tested all work with 7.6.3, although 7.6 gives the warning:
You are using a new version of LLVM that hasn't been tested yet! We will try though...
I suspect that the LLVM backend thinks I have a different version than I actually have, or maybe the LLVM tools think I have a different CPU than I have:
dafis@schwartz:~/JNthPrime> llc --version LLVM (http://llvm.org/): LLVM version 3.2svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx
Registered Targets: arm - ARM ppc32 - PowerPC 32 ppc64 - PowerPC 64 thumb - Thumb x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 dafis@schwartz:~/JNthPrime> opt --version LLVM (http://llvm.org/): LLVM version 3.2svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx
But my CPU is a Core i5, not i7.
Can somebody confirm or deny that that may be the cause? _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/ghc-devs

GHC 7.6 did not support LLVM 3.2 - it was only tested with up-to LLVM 3.1.
The odd version number for LLVM 3.2 was a known problem with their
tarball, they forgot to remove the 'svn' suffix. This shouldn't be a
problem for GHC, it should correctly parse the right thing anyway.
Can you try another LLVM version? LLVM 3.2 has been known to be
particularly problematic - I believe me and David looked into this a
while back, and we couldn't get even get the compiler to bootstrap
with it at one point, let alone figure out what the hell was going on
(I'll see if I can find the ticket related to this). LLVM 3.3 or LLVM
3.4 should work just fine, and you can put them on the front of your
$PATH before running the testsuite to check this.
On Thu, Apr 24, 2014 at 1:57 PM, Daniel Fischer
On Thursday 24 April 2014, 14:49:18, Carter Schonwald wrote:
What OS? Is this on a vm?
Oops, sorry. openSuSE 12.3 (64 bit), nothing virtual.
I7-avx is the instruction family. I5 will be ok.
Okay, then it's probably that what openSuSE calls 3.2 is not what GHC thinks 3.2 is.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

(And note I base this assumption on the principle that e.g. ARM is
currently working relatively well with the latest versions of LLVM,
where that's the only option for the code generator. But we've had
other bugs exposed here before, or exposed LLVM bugs, so it may just
be whack-a-mole...)
On Thu, Apr 24, 2014 at 2:04 PM, Austin Seipp
GHC 7.6 did not support LLVM 3.2 - it was only tested with up-to LLVM 3.1.
The odd version number for LLVM 3.2 was a known problem with their tarball, they forgot to remove the 'svn' suffix. This shouldn't be a problem for GHC, it should correctly parse the right thing anyway.
Can you try another LLVM version? LLVM 3.2 has been known to be particularly problematic - I believe me and David looked into this a while back, and we couldn't get even get the compiler to bootstrap with it at one point, let alone figure out what the hell was going on (I'll see if I can find the ticket related to this). LLVM 3.3 or LLVM 3.4 should work just fine, and you can put them on the front of your $PATH before running the testsuite to check this.
On Thu, Apr 24, 2014 at 1:57 PM, Daniel Fischer
wrote: On Thursday 24 April 2014, 14:49:18, Carter Schonwald wrote:
What OS? Is this on a vm?
Oops, sorry. openSuSE 12.3 (64 bit), nothing virtual.
I7-avx is the instruction family. I5 will be ok.
Okay, then it's probably that what openSuSE calls 3.2 is not what GHC thinks 3.2 is.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
-- Regards,
Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

On Thursday 24 April 2014, 14:04:13, Austin Seipp wrote:
Can you try another LLVM version? LLVM 3.2 has been known to be particularly problematic - I believe me and David looked into this a while back, and we couldn't get even get the compiler to bootstrap with it at one point, let alone figure out what the hell was going on (I'll see if I can find the ticket related to this). LLVM 3.3 or LLVM 3.4 should work just fine, and you can put them on the front of your $PATH before running the testsuite to check this.
Okay, I got myself a 3.4, and it seems to work. I'll re-run the testsuite and see what failures remain.

We should reject LLVM 3.2 if it's known to be bad - I remember running into this on the RPi too. LlvmCodeGen already checks the version number and emits warnings if it's too old or too new. On 24/04/2014 20:04, Austin Seipp wrote:
GHC 7.6 did not support LLVM 3.2 - it was only tested with up-to LLVM 3.1.
The odd version number for LLVM 3.2 was a known problem with their tarball, they forgot to remove the 'svn' suffix. This shouldn't be a problem for GHC, it should correctly parse the right thing anyway.
Can you try another LLVM version? LLVM 3.2 has been known to be particularly problematic - I believe me and David looked into this a while back, and we couldn't get even get the compiler to bootstrap with it at one point, let alone figure out what the hell was going on (I'll see if I can find the ticket related to this). LLVM 3.3 or LLVM 3.4 should work just fine, and you can put them on the front of your $PATH before running the testsuite to check this.
On Thu, Apr 24, 2014 at 1:57 PM, Daniel Fischer
wrote: On Thursday 24 April 2014, 14:49:18, Carter Schonwald wrote:
What OS? Is this on a vm?
Oops, sorry. openSuSE 12.3 (64 bit), nothing virtual.
I7-avx is the instruction family. I5 will be ok.
Okay, then it's probably that what openSuSE calls 3.2 is not what GHC thinks 3.2 is.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Look at the output of ghc --info It will tell you what opt /LLC ghc will invoke by default. ghc 7.8 should work with llvm 3.3/3.4 On Thursday, April 24, 2014, Daniel Fischer < daniel.is.fischer@googlemail.com> wrote:
On Thursday 24 April 2014, 14:49:18, Carter Schonwald wrote:
What OS? Is this on a vm?
Oops, sorry. openSuSE 12.3 (64 bit), nothing virtual.
I7-avx is the instruction family. I5 will be ok.
Okay, then it's probably that what openSuSE calls 3.2 is not what GHC thinks 3.2 is.
participants (4)
-
Austin Seipp
-
Carter Schonwald
-
Daniel Fischer
-
Simon Marlow