4 ms·

Sure, but the supported class of languages is very broad and certainly not limited to C/C++.

yorwba 9y ago
Those languages are however supported mostly by (accidentally or deliberately) being similar to C/C++. Not only does the IR need to be able to express certain constraints of the language semantics (IIRC, there have already been changes to better accommodate Rust), but the kinds of IR patterns the compiler frontend generates might not get optimized if they are too un-C-like.
- 14113 9y ago
  LLVM is targeted by both Haskell and Idris - two of the most un-C/C++-like languages I've ever come across.
  - yorwba 9y ago
    I was curious about how that works, so I searched a bit and found this description of how GHC's GC works in LLVM https://www.reddit.com/r/haskell/comments/3qix1e/how_does_ghcs_garbage_collection_work_on_llvm/cwfmp6j/ https://www.reddit.com/r/haskell/comments/3qix1e/how_does_gh... Some highlights: Now, before GHC generates assembly code (abiding by the calling conventions previously described), it also needs to optimize it. It optimizes a form called "Cmm", which is like a very low level compiler language for performing optimizations. This language does include functions. When you use the LLVM backend, GHC translates every Cmm function to an LLVM function. In order for everything to work out, we patched LLVM so that functions can have an annotation saying they follow the GHC calling convention. ... What this means is, we have completely side stepped LLVM's support for GC. So the support mostly comes from the Haskell side, by compiling to the C-like Cmm (I think that name comes from C--, the idea being a language between assembly and C in abstraction level) and patching or otherwise working around the part where LLVM's feature set wasn't appropriate.
    - sanxiyn 9y ago
      Note that mentioned LLVM patches are now upstream. http://llvm.org/docs/LangRef.html#calling-conventions http://llvm.org/docs/LangRef.html#calling-conventions documents "GHC convention", for example.

Those languages are however supported mostly by (accidentally or deliberately) being similar to C/C++. Not only does the IR need to be able to express certain constraints of the language semantics (IIRC, there have already been changes to better accommodate Rust), but the kinds of IR patterns the compiler frontend generates might not get optimized if they are too un-C-like.

14113 9y ago
LLVM is targeted by both Haskell and Idris - two of the most un-C/C++-like languages I've ever come across.
- yorwba 9y ago
  I was curious about how that works, so I searched a bit and found this description of how GHC's GC works in LLVM https://www.reddit.com/r/haskell/comments/3qix1e/how_does_ghcs_garbage_collection_work_on_llvm/cwfmp6j/ https://www.reddit.com/r/haskell/comments/3qix1e/how_does_gh... Some highlights: Now, before GHC generates assembly code (abiding by the calling conventions previously described), it also needs to optimize it. It optimizes a form called "Cmm", which is like a very low level compiler language for performing optimizations. This language does include functions. When you use the LLVM backend, GHC translates every Cmm function to an LLVM function. In order for everything to work out, we patched LLVM so that functions can have an annotation saying they follow the GHC calling convention. ... What this means is, we have completely side stepped LLVM's support for GC. So the support mostly comes from the Haskell side, by compiling to the C-like Cmm (I think that name comes from C--, the idea being a language between assembly and C in abstraction level) and patching or otherwise working around the part where LLVM's feature set wasn't appropriate.
  - sanxiyn 9y ago
    Note that mentioned LLVM patches are now upstream. http://llvm.org/docs/LangRef.html#calling-conventions http://llvm.org/docs/LangRef.html#calling-conventions documents "GHC convention", for example.