<div dir="ltr"><div>> Hi,</div><div>> </div><div>> I’m trying to implement a bitcode producing llvm backend[1], which would potentially</div><div>> allow to use a range of llvm versions with ghc. However, this is only tangentially</div><div>> relevant to the improved llvm backend, as Austin correctly pointed out[2], as there are</div><div>> other complications besides the fragility of the textual representation.</div><div>> </div><div>> So this is mostly only relevant to the improved ir you mentioned. The bitcode code gen</div><div>> plugin right now follows mostly the textual ir generation, but tries to prevent the</div><div>> ubiquitous symbol to i8* casting. The llvm gen turns cmm into ir, at this point however</div><div>> at that point, the wordsize has been embedded already, which means that the current</div><div>> textual llvm gen as well as the bitcode llvm gen try to figure out if relative access is</div><div>> in multiple wordsizes to use llvms getElementPointer.</div><div><br></div><div>That sounds interesting, do you know where could I find out more about this?</div><div>(both when it comes to the current LLVM codegen and yours)</div><div><br></div><div>> I don’t know if generating llvm from stg instead of cmm would be a better</div><div>> approach, which is what ghcjs and eta do as far as I know.</div><div><br></div><div>Wouldn't a step from STG to LLVM be much harder (LLVM IR is a pretty low-level</div><div>representation compared to STG)? There are also a few passes on the Cmm level</div><div>that seem necessary, e.g., `cmmLayoutStack`.</div><div><br></div><div>Cheers,</div><div>Michal</div><div><br></div></div>