On 01/06/2011 07:11, Manuel M T Chakravarty wrote:
Simon Marlow:
On 30/05/2011 14:59, Manuel M T Chakravarty wrote:
It is no secret that Apple moves away from the traditional GCC
backend to LLVM. In fact, Xcode (which bundles all command line
developer tools on the Mac) today comes with two flavours of gcc:
'gcc' and 'llvm-gcc', which AFAIK only differ in the backend that is
being used. Currently, the default is the traditional GCC backend,
but it takes no precognition to realise that this will eventually
change. The 'gcc' executable will use the LLVM backend and, at least
for a while, the traditional backend will still be available under a
different name.
Unfortunately, GHC will break at this point as the LLVM backend does
not support pinned global registers. ('llvm-gcc' happily accepts the
register assignment, but fails with a runtime error during code
generation.)
This shouldn't be a problem. We don't use pinned global registers any more,
except in one place - the GC (see rts/sm/GCTDecl.h). There it's optional, but
you lose a bit of performance by not using a pinned register. It's not a huge
deal.
Have you tried building GHC with llvm-gcc? I think I tried it on the RTS a
year or so ago to check the LLVM output against gcc (LLVM wasn't quite as good
at the time).
Yes, I tried and it failed, while compiling the RTS, with
sorry, unimplemented: LLVM cannot handle register variable ‘R1’, report
a bug
This was using the 64bit version of GHC. I'll have a closer look.
Perhaps that was when compiling StgCRun.c? It doesn't actually need
register variables (on x86_64 at least), but it does include the header
files, so that probably needs some #ifdefery somewhere for llvm-gcc.
The other place, as I mentioned above, is rts/sm/GCTDecl.h, which will
need to use a different method for declaring the garbage collector's
thread-local state variable, gct. On x86_64 I found that using a fixed
register was the fastest, but using a thread-local variable (the
__thread modifier) also works.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
