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
