<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>I wrote the initial implementation of the LLVM code generator many years ago now.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers</div><div>David</div><div><br>On Jun 3, 2016, at 8:25 AM, Nicola Gigante <<a href="mailto:nicola.gigante@gmail.com">nicola.gigante@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Hi all,</div><div class=""><br class=""></div><div class="">while looking at the GHC 8 Trac page I encountered the page</div><div class="">about the plans for the improved LLVM backend:</div><div class=""><br class=""></div><a href="https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend" class="">https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend</a><div class=""><br class=""></div><div class="">I know nearly nothing about the internals of the GHC backend so </div><div class="">I may be asking something trivial, but from reading that page</div><div class="">I understand that GHC currently calls LLVM command line tools</div><div class="">to optimize and compile the IR, is it right?</div><div class=""><br class=""></div><div class=""><div class="">LLVM is a C++ library, but it also exports a portable and stable C API</div><div class="">which I think is already covered by the llvm-general package.</div></div><div class=""><br class=""></div><div class="">So as someone who worked on LLVM in the past, and appreciated</div><div class="">its library-based integration-friendly design I’m wondering why is</div><div class="">GHC using the command line tools instead of linking to the library?</div><div class=""><br class=""></div><div class="">Best Regards,</div><div class="">Nicola</div><div class=""><br class=""></div><div class=""><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>ghc-devs mailing list</span><br><span><a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a></span><br><span><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a></span><br></div></blockquote></body></html>