GCC, Mac OS X & the future

[Manuel M T Chakravarty]

Simon Marlow:
> 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.

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?

Cheers,
Manuel