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@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs