Why does the LLVM invoke command-line tools instead of using the library?

[David Terei]

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 <nicola.gigante at gmail.com> 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
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160605/12a885b5/attachment.html>