Will GHC 6.14 with LLVM use LLVM C compiler to compile external C Libraries
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?
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-g... [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
I am not that familiar with LLVM, if anything it complicates matters, rather than making things easier. "The llvm-ld program has limited support for native code generation, when using the -native or -native-cbe options. Native code generation is performed by converting the linked bitcode into native assembly (.s) or C code and running the system compiler (typically gcc) on the result." so it seems that the gcc support infrastructure that is currently integrated into ghc will still be required. Then the question arises what library formats will ghc use under the circumstances ?(.bc, .a) and how will the two be integrated? On windows, most c/c++ public domain libraries are either compiled with ms-c or gcc which have their standard library formats. which in many cases come pre-compiled with the libraries. Becuase of this I would assume retention of the .a format, but perhaps compiling haskell to .bc would offer opportunities for link time optimisation? In fact I would like a lot more information on what is being proposed with respect of a LLVM backend and any changes to the compiler tool chain.
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
On Thu, Sep 9, 2010 at 9:08 PM, John Lask
so it seems that the gcc support infrastructure that is currently integrated into ghc will still be required. Then the question arises what library formats will ghc use under the circumstances ?(.bc, .a) and how will the two be integrated?
As far as I know, the same files are used. See [1], for example. [1] http://llvm.org/docs/GoldPlugin.html Cheers! -- Felipe.
On 9 September 2010 22:10, Mathew de Detrich
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?
I don't think it would make it any easier to use C/C++ from Haskell at
the moment. LLVM for static compilation works by
compiling to assembly. After that it has no support. So we use gcc to
finish off the rest of the job; producing object code and linking.
There is a pretty cool project going on in LLVM at the moment of
integrating an assembler into LLVM so that it can directly produce
object code. This should mean that the LLVM backend wouldn't need gcc
anymore (but obviously gcc will still be needed by ghc as a whole).
As David Peixotto mentioned though, the ghc runtime can't be built by
clang. There is probably a few reason but a main one is that Clang
doesn't support gcc's global register variable extension (register
pinning). The LLVM guys also have no plans to support this feature so
unless we want to stop using this extension we are stuck with using gcc.
I think the main advantage to trying to use Clang for compiling C/C++
would be that it would enable us to do whole program optimisation
across Haskell and C/C++. It could also make cross compiling slightly
easier. These ideas are defiantly something I'd like to investigate
more in the future.
On 10 September 2010 10:08, John Lask
In fact I would like a lot more information on what is being proposed with respect of a LLVM backend and any changes to the compiler tool chain.
What would you like to know? If you're talking just about the new LLVM backend for GHC (not the proposal here of using clang) then the effect on the end user is nothing. The LLVM backend compiles an individual Haskell module to LLVM assembly, which is then compiled to native assembly by the 'llc' tool. This gets you now to the same place as the native code generator, where gcc is used to compiled the assembly to an object file. Obviously there is a new dependency on having LLVM 2.7 or greater installed but that should be it. Cheers, David
This is the main thing I was getting behind, making cross compiling slightly
easier (in regards to C/C++ sources). As also pointed out, whole program
optimization can be one major benefit to integrating Clang like this.
On Fri, Sep 10, 2010 at 11:01 AM, David Terei
I think the main advantage to trying to use Clang for compiling C/C++ would be that it would enable us to do whole program optimisation across Haskell and C/C++. It could also make cross compiling slightly easier. These ideas are defiantly something I'd like to investigate more in the future.
Cheers,
David _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
I wonder if llvm-gcc supports it's own (gcc) extensions. If it supports then there is no need to stuck in clang right now.
2010/9/10 kyra
I wonder if llvm-gcc supports it's own (gcc) extensions. If it supports then there is no need to stuck in clang right now.
It doesn't support the one I mentioned before of global register variables. I haven't looked for a while so maybe this has changed but llvm-gcc used to incorrectly claim that it supported this feature simply because it supported the syntax. The actual implementation of the extension doesn't work anything like gcc though so most code using the feature will break if compiled with llvm-gcc. Global register variables needs backend support (e.g register allocator) to be implemented so llvm-gcc and clang are in the same boat here, both not supporting it.
participants (6)
-
David Peixotto -
David Terei -
Felipe Lessa -
John Lask -
kyra -
Mathew de Detrich