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
On Mon, Nov 28, 2016 at 2:43 AM Moritz Angermann
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