> Hi, > > I’m trying to implement a bitcode producing llvm backend[1], which would potentially > allow to use a range of llvm versions with ghc. However, this is only tangentially > relevant to the improved llvm backend, as Austin correctly pointed out[2], as there are > other complications besides the fragility of the textual representation. > > So this is mostly only relevant to the improved ir you mentioned. The bitcode code gen > plugin right now follows mostly the textual ir generation, but tries to prevent the > ubiquitous symbol to i8* casting. The llvm gen turns cmm into ir, at this point however > at that point, the wordsize has been embedded already, which means that the current > textual llvm gen as well as the bitcode llvm gen try to figure out if relative access is > in multiple wordsizes to use llvms getElementPointer.
That sounds interesting, do you know where could I find out more about this? (both when it comes to the current LLVM codegen and yours) > 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`. Cheers, Michal
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs