On Mon, Nov 28, 2016 at 2:43 AM Moritz Angermann <[email protected]> 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
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
