GHC, Clang & XCode 4.2

[David Peixotto]

On Oct 6, 2011, at 7:32 AM, Simon Marlow wrote:

> On 05/10/2011 09:46, austin seipp wrote:
>> There has been recent discussion on the Homebrew bug tracker
>> concerning the upcoming XCode 4.2 release by Apple, which has
>> apparently just gone GM (meaning they're going to make a real release
>> on the app store Real Soon Now.)
>> 
>> The primary concern is that XCode will no longer ship GCC 4.2 at all,
>> it seems. XCode 4.0&  4.1 merely set 'llvm-gcc' as the default
>> compiler, and GHC's `configure` script was adjusted to find the
>> `gcc-4.2` binary. If you have old XCode's installed, then you may have
>> the binaries laying around, but I doubt they'll be on your $PATH, and
>> anybody doing a fresh install is SOL.
>> 
>> It seems Clang 3.0 will now be the default compiler, with llvm-gcc as
>> a deprecated option, probably removed in XCode 4.3. It doesn't matter
>> really, because both of them do not work with GHC, because of its use
>> of either A) Global register variables of any kind, or B) the __thread
>> storage modifier.
>> 
>> David Peixotto did some work on this not too long ago as the issue of
>> compiling with Clang was raised. His branches include changes which
>> make the 'gct' variable use pthread_getspecific rather than __thread
>> for TLS and then as an optimization use inline ASM to grab the value
>> out of the variable, with an impact of about 9% it seems, but that's
>> on nofib and I don't know if it was -threaded. He also included a
>> version which passes the 'gct' around as a parameter to all GCC
>> functions which is a bit uglier but may give some better performance I
>> guess. (The discussion is from here IIRC.) I suppose the real perf
>> killer here is probably -threaded code.
>> 
>> https://github.com/dmpots/ghc
>> 
>> Was there ever any decision on which route to take for this issue? The
>> parameter passing solution looks quite uglier IMO but it may be
>> necessary for performance.
> 
> I'm happy to incorporate the parameter-passing changes if necessary.  I think it should only be important in the inner loop of the GC (scavenge_block/evacuate and the functions called from there).  If someone sends me a working patch, I can clean it up as much as possible.

I will take a look at getting the patches to work with GHC head. To support llvm-gcc we need two basic things:

1. autoconf support to detect when we are compiling with llvm-gcc
2. a work-around for tls in the gc

My old patches take care of both 1 and 2. For #2 the easy approach is using pthread_getspecific which is a pretty small change. Passing gct as a parameter is much uglier more invasive change, but I had it working at some point. It could perhaps be made less ugly by only passing it around in the "important" functions.

Supporting clang is going to require more changes. The last time I tried there were problems with the preprocessor that made it not work. I just tried again yesterday and ran into a problem generating makefile dependencies because apparently clang does not allow both the -MM and -MF flags (http://llvm.org/bugs/show_bug.cgi?id=8312).


> Note that some of the overhead measured by David is coming from using the LLVM backend to gcc instead of gcc's own backend.  In my own measurements a few months ago I found LLVM generated slower (but smaller) code for the GC.  Maybe this will change over time.  It's also possible that the current GC code is tuned for gcc - at various times in the past I've gone through and tweaked the code to get good assembly out (much as we teak Haskell to get good Core :-).
> 
> Cheers,
> 	Simon
> 
> 
>> I'm just posting this here as a reminder as this is probably going to
>> become a problem pretty quickly for anybody who uses Lion or modern
>> XCode and also likes using GHC, so it should probably be sorted out.
>> :) I'm still on SL using XCode 4 so it's not an issue for me, but it
>> will be for any future Mac endeavors. Hopefully they get support for
>> __thread or something equivalent soon, because nobody likes
>> performance hits, but it doesn't seem like we have a choice.
>> 
> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>