Status of "Improved LLVM backend"

[Michal Terepeta]

> 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.

That sounds interesting, do you know where could I find out more about this?
(both when it comes to the current LLVM codegen and yours)

> 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.

Wouldn't a step from STG to LLVM be much harder (LLVM IR is a pretty
low-level
representation compared to STG)? There are also a few passes on the Cmm
level
that seem necessary, e.g., `cmmLayoutStack`.

Cheers,
Michal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161127/e32ea3f2/attachment.html>