4 ms·

> LLVM is language agnostic There exists no such thing as "language agnostic". Every intermediate representation contains properties (very often implicitly) th

> LLVM is language agnostic There exists no such thing as "language agnostic". Every intermediate representation contains properties (very often implicitly) that are specific at least to a class of programming languages.

whatshisface 9y ago
If the intermediate representation is no more language-specific than x86, then it isn't really the compiler that's language-specific: it's modern computer architecture.
- FeepingCreature 9y ago
  LLVM IR is fairly C specific. For instance, you better not be trying to write a language where null pointer access is defined...
  - nicwilson 9y ago
    We compile D with LLVM. Null pointer access is defined to crash, unlike C/C++ where it is undefined.
    - pcwalton 9y ago
      Are you adding explicit checks (possibly using fault maps to optimize them)? Because if not, you're depending on undefined behavior.
      - nicwilson 9y ago
        That is only necessary for single objects that are bigger than one page which, we dont currently do (but should). Arrays are no problem since we check the bounds, only raw pointers cause problems.
        pcwalton 9y ago
        No, it is necessary in all cases. Look at the InstCombine code I linked in a sibling comment…
  - pcwalton 9y ago
    This post is correct. Load of a null pointer is undefined behavior in LLVM. If you don't believe me, here is the code that optimizes based on this. https://code.woboq.org/llvm/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp.html#1033 https://code.woboq.org/llvm/llvm/lib/Transforms/InstCombine/... https://code.woboq.org/llvm/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp.html#_ZL24canSimplifyNullLoadOrGEPRN4llvm8LoadInstEPNS_5ValueE https://code.woboq.org/llvm/llvm/lib/Transforms/InstCombine/...
- discoursism 9y ago
  Or maybe another way to put it would be that the given language is hardware-antagonistic.
catpolice 9y ago
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.
      - 9y ago

whatshisface 9y ago

If the intermediate representation is no more language-specific than x86, then it isn't really the compiler that's language-specific: it's modern computer architecture.

FeepingCreature 9y ago
LLVM IR is fairly C specific. For instance, you better not be trying to write a language where null pointer access is defined...
- nicwilson 9y ago
  We compile D with LLVM. Null pointer access is defined to crash, unlike C/C++ where it is undefined.
  - pcwalton 9y ago
    Are you adding explicit checks (possibly using fault maps to optimize them)? Because if not, you're depending on undefined behavior.
    - nicwilson 9y ago
      That is only necessary for single objects that are bigger than one page which, we dont currently do (but should). Arrays are no problem since we check the bounds, only raw pointers cause problems.
      - pcwalton 9y ago
        No, it is necessary in all cases. Look at the InstCombine code I linked in a sibling comment…
- pcwalton 9y ago
  This post is correct. Load of a null pointer is undefined behavior in LLVM. If you don't believe me, here is the code that optimizes based on this. https://code.woboq.org/llvm/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp.html#1033 https://code.woboq.org/llvm/llvm/lib/Transforms/InstCombine/... https://code.woboq.org/llvm/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp.html#_ZL24canSimplifyNullLoadOrGEPRN4llvm8LoadInstEPNS_5ValueE https://code.woboq.org/llvm/llvm/lib/Transforms/InstCombine/...
discoursism 9y ago
Or maybe another way to put it would be that the given language is hardware-antagonistic.

catpolice 9y ago

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.
    - 9y ago