GCC, Mac OS X & the future
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Wed Jun 1 14:30:07 CEST 2011
> 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
>>> 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.
Yes, it's in 'StgCRun.c'. Ok, and how about on i386 (or do you want to phase that arch out)?
> 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.
Just to make sure I understand correctly, are you saying that using a thread-local variable is already implemented as an option, or are you saying that we could implement it to solve the problem I am describing? And again, what about i386, does that need a register or is a thread-local variable fine as well?
More information about the Cvs-ghc