Status of "Improved LLVM backend"

[Moritz Angermann]

Hi,

I’m trying to implement a bitcode producing llvm backend[1], which would potentially
allow to use a range of llvm versions with ghc. However, this is only tangentially
relevant to the improved llvm backend, as Austin correctly pointed out[2], as there are
other complications besides the fragility of the textual representation.

So this is mostly only relevant to the improved ir you mentioned. The bitcode code gen
plugin right now follows mostly the textual ir generation, but tries to prevent the
ubiquitous symbol to i8* casting. The llvm gen turns cmm into ir, at this point however
at that point, the wordsize has been embedded already, which means that the current
textual llvm gen as well as the bitcode llvm gen try to figure out if relative access is
in multiple wordsizes to use llvms getElementPointer.  I don’t know if generating
llvm from stg instead of cmm would be a better approach, which is what ghcjs and eta
do as far as I know.

Cheers,
 moritz

— 
[1]: https://github.com/ghc-proposals/ghc-proposals/pull/25
[2]: https://github.com/ghc-proposals/ghc-proposals/pull/25#issuecomment-261697189

> On Nov 27, 2016, at 3:14 AM, Michal Terepeta <michal.terepeta at gmail.com> wrote:
> 
> Hi all,
> 
> I was wondering what’s the current status of the “Improved LLVM backend” project
> ( https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend ). The page mentions a
> few main problems, but some seem to be already fixed:
> 1) Using/supporting only one version of LLVM.
>    This has been done AFAIK.
> 2) Prebuilt binaries to be shipped together with GHC.
>    I can't find anything about this. Is there a ticket? Has there been any
>    progress on this?
> 3) Adding support for split-objs
>    I found a ticket about it: https://ghc.haskell.org/trac/ghc/ticket/8300
>    which was closed as WONTFIX in favor of split-sections. So I guess this can
>    also be considered as done.
> 4) Figuring out what LLVM optimizations are useful.
>    Again, I can seem to find anything here. Has anyone looked at this?
>    I only found an issue about this:
>    https://ghc.haskell.org/trac/ghc/ticket/11295
> 
> The page also mentions that the generated IR could be improved in many cases,
> but it doesn't link to any tickets or discussions. Is there something I could
> read to better understand what are the main problems?
> The only thing I can recall is that proc point splitting is likely to cause
> issues for LLVM's ability to optimize the code. (but I only found a couple of email
> threads about this but couldn't find any follow-ups)
> 
> Thanks,
> Michal
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs