Status of "Improved LLVM backend"

Michal Terepeta michal.terepeta at
Tue Nov 29 19:09:58 UTC 2016

On Mon, Nov 28, 2016 at 2:43 AM Moritz Angermann <moritz at>
> 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
> 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
> > > 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
> > representation compared to STG)? There are also a few passes on the Cmm
> > 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
> 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
of using current Cmm for LLVM backend, or just adding some comments in the

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list