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