Fwd: GHC, Clang & XCode 4.2

17 Oct 2011


      I think, you meant to reply to the list and not just to me.
...
Von: "B. Scott Michel" 
Betreff: Re: GHC, Clang & XCode 4.2
Datum: 15 October 2011 12:32:36 
An: Manuel M T Chakravarty 
Antwort an: scooter.phd@gmail.com
Simon:
What are the performance penalties, specifically? I ask because I might still have commit privs to llvm from the errors of a misspent post-doc era, so could probably help push a patch to llvm if needed.
That said, though, FreeBSD moved to llvm because itKs not GPL and it generates better code.
-scooter
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Manuel M T Chakravarty 
Sender: glasgow-haskell-users-bounces@haskell.org
Date: Thu, 13 Oct 2011 13:11:40 
To: Simon Marlow
Cc: GHC Users Mailing List
Subject: Re: GHC, Clang & XCode 4.2
Just FYI, Xcode 4.2 is live in the Mac App Store now, and it has some nice goodies (i.e., many who develop for iOS and probably also OS X will probably adopt it soon).
Manuel
PS: Sorry for not having participated in the discussion on how to solve this, but I have too many loose ends right now.
Simon Marlow:
...
On 11/10/2011 18:45, David Peixotto wrote:
...
Ok, I have attached a set of patches to support building the GHC
runtime with llvm-gcc. The patches are based off of commit
29a97fded4010bd01aa0a17945c84258e285d421 which was last Friday's HEAD.
These patches are also available from my github repository on the
llvm-gcc branch at
git://github.com/dmpots/ghc.git
There are three patches:
0001- Uses pthread_getspecific and pthread_setspecfic to
        	   access gct when the `llvm_CC_FLAVOR` CPP macro is
        	   set
0002- Modifies the configure scripts to set the
         `llvm_CC_FLAVOR` macro when compiling with an llvm
         based compile (either llvm-gcc or clang)
0003- Passes the gct variable as a parameter in the GC. This
        	   change is parameterized with CPP macros so that it
        	   is only in effect when compiling for an llvm-based
        	   compiler.
The patches 0001 and 0002 provide the minimal support needed to build
GHC with llvm-gcc. The 0003 patch is there to limit the performance
hit we get by going through pthread functions to access the gct. I
think the 0001 and 0002 patches should not be very controversial, but
the 0003 patch is a more invasive change and perhaps Simon Marlow will
want to clean it up before it is applied.
Thanks, I'll take a look at these soon.
Just a thought, but someone might want to write a blog post about how Apple's choice to move to llvm-gcc is imposing a performance penalty on us here, and get it up on Reddit.  That would give the issue some publicity (they love that sort of thing on Reddit), and might result in some action.  I'd be happy to proof read a blog post before publication.  Some simple benchmarks would be needed - one option is to use GHC itself with the various combinations of compilers + RTS changes, or there are a small set of GC benchmarks in nofib/gc.
Cheers,
  Simon
...
I ran a validate with the patches, and found one additional failure
when going through an llvm-based compiler. There were no additional
failures when using a gcc compiler even with my patches applied. The
additional failure is the cgrun071 test which tests the popCnt
primitives. I'm going to look into why that test fails, but I think
the patches should be safe to apply as it would only show up when
compiling with llvm-gcc, which is currently impossible without these
patches.
-David
On Oct 7, 2011, at 10:30 AM, David Peixotto wrote:
...
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@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users