Why does the LLVM invoke command-line tools instead of using the library?
davidterei at gmail.com
Sun Jun 5 17:23:59 UTC 2016
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.
> 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:
> 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,
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs