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