I'm not sure using Clang would make it any *easier* to use external sources, but it could provide opportunities for optimizing across the C/Haskell boundary. The main difficulty in getting it all working correctly is the linking step. The Mac OSX linker can [link together llvm bitcode][1] for link-time optimization, but the support on Linux is less mature. You have to use the [gold linker][2] if you want to optimize bitcode at link time.
I made an attempt in May to compile the GHC runtime with Clang. The process is documented in this [blog post][3]. I was interested in using LLVM's link-time optimization to optimize parts of the runtime together with a compiled Haskell program. While I never got that far, just getting the GHC runtime to compile with Clang was a bit difficult. It uses some GCC specific extensions (pinned global registers, and __thread for thread local data) that did not work well with Clang. In particular, lack of support for these two extensions made it impossible to compile the threaded runtime. I think it would be very interesting to see what kind of performance benefits we could get from using the LLVM backend in GHC to link with LLVM bitcode generated by Clang. [1] http://developer.apple.com/library/mac/releasenotes/DeveloperTools/RN-llvm-gcc/index.html#//apple_ref/doc/uid/TP40007133-CH1-SW14 [2] http://llvm.org/docs/GoldPlugin.html [3] http://www.dmpots.com/blog/2010/05/08/building-ghc-with-clang.html On Sep 9, 2010, at 7:10 AM, Mathew de Detrich wrote: > Since GHC 6.14 will (hopefully) be use LLVM as a default backend, an idea has > occured to me > > Should GHC also use the clang (C/C++->LLVM compiler) on external C library > sources which are used with certain Haskell packages (such as gtk) when LLVM > does become a default backend for GHC. The consensus is that since Clang will > also produce LLVM 'assembler', it can be very easily linked with the LLVM > 'assembler' produced by GHC's LLVM backend, making the process of using > external C sources a lot easier. Parts of Clang required could even be > integrated into GHC (although this may be tricky since its coded in C++). It > should also hopefully make using Haskell packages on windows that use C > sources less painful > > Clang could also make using FFI with C++ much easier (for reasons stated > above) > > Thoughts? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
