It seems like the main problem, for implementers of languages significantly different to C and C-like languages, is that LLVM doesn't offer direct access to har

It seems like the main problem, for implementers of languages significantly different to C and C-like languages, is that LLVM doesn't offer direct access to hardware registers or the stack, and it has built-in calling conventions. (Although, that's kind of the point of LLVM IR. GHC implementers wanted certain values to be always kept in registers, from what I understood of it.) This was a problem in writing an LLVM backend for both the Glasgow Haskell Compiler and the Standard ML of New Jersey Compiler. It seems like it was easier for the GHC implementers, because they were already able to compile their semantic IR (the spineless tagless G-machine) into C--/Cmm, which conceptually isn't that different from LLVM IR. The SML implementers compiled to the continuation passing style, which is harder to map to LLVM IR. However, the GHC implementers still had to extend LLVM with a custom calling convention, so it was still challenging. Paper on the LLVM backend for GHC Haskell: https://llvm.org/pubs/2010-09-HASKELLSYM-LLVM-GHC.pdf https://llvm.org/pubs/2010-09-HASKELLSYM-LLVM-GHC.pdf Paper on the LLVM backend for SML/NJ: https://people.cs.uchicago.edu/~jhr/papers/2020/ifl-smlnj-llvm.pdf https://people.cs.uchicago.edu/~jhr/papers/2020/ifl-smlnj-ll...