I wrote the initial implementation of the LLVM code generator many years ago now.
At the time, no Haskell bindings suitable for block code generation existed. I was doing the work as per of an undergraduate thesis and so with time pressures went with the quicker option of producing a text file rather than implementing bindings. That said, there are advantages of this approach: The LLVM backend can ship with GHC by default as it has no dependency on LLVM libraries. Not worrying about packaging or linking against LLVM for a new experimental backend was great. I also don't believe we loose much speed by going through the file system. When I last tried to measure this, 75% of the time for the LLVM code generation was spent in optimization, less than 10% in parsing the file. These were rough numbers so perhaps I made a mistake in measuring them. The text file format also was originally white stable and so made it easy to choose different LLVM versions. This has become more of a problem as time has progressed, so there is a push to bundle LLVM with GHC to fix on one version. Cheers David > On Jun 3, 2016, at 8:25 AM, Nicola Gigante <[email protected]> wrote: > > Hi all, > > while looking at the GHC 8 Trac page I encountered the page > about the plans for the improved LLVM backend: > > https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend > > I know nearly nothing about the internals of the GHC backend so > I may be asking something trivial, but from reading that page > I understand that GHC currently calls LLVM command line tools > to optimize and compile the IR, is it right? > > LLVM is a C++ library, but it also exports a portable and stable C API > which I think is already covered by the llvm-general package. > > So as someone who worked on LLVM in the past, and appreciated > its library-based integration-friendly design I’m wondering why is > GHC using the command line tools instead of linking to the library? > > Best Regards, > Nicola > > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
