Status of "Improved LLVM backend"

[Michal Terepeta]

On Mon, Nov 28, 2016 at 2:43 AM Moritz Angermann <moritz at lichtzwerge.de>
wrote:
[...]
> For the llvm code gen in ghc it’s usually the `_fast` suffix functions.
See [1] and
> the `genStore_fast` 30 lines further down.  My bitcode llvm gen follows
that file [1],
> almost identically, as can be seen in [2].  However the `_fast` path is
currently
> disabled.
>
> An example of the generated ir for the current llvm backend, and the
bitcode backend,
> (textual ir, via llvm-dis) can be found in [3] and [4] respectively.

Cool, thanks a lot for the links!

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

> There is certainly a tradeoff between retaining more high-level
information and
> having to lower them oneself.  If I remember luite correctly, he said he
had a similar
> intermediate format to cmm, just not cmm but something richer, which
allows
> to better target javascript.  The question basically boils down to asking
if cmm is
> too low-level for llvm already; the embedding of wordsizes is an example
where I think
> cmm might be to low-level for llvm.

Ok, I see. This is quite interesting - I'm wondering if it makes sense to
collect thought/ideas like that somewhere (e.g., a wiki page with all the
issues
of using current Cmm for LLVM backend, or just adding some comments in the
code).

Thanks,
Michal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161129/4e4e1c11/attachment-0001.html>