Hacker News Reader

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.

View on HN

LLVM IR is fairly C specific. For instance, you better not be trying to write a language where null pointer access is defined...

We compile D with LLVM. Null pointer access is defined to crash, unlike C/C++ where it is undefined.

Are you adding explicit checks (possibly using fault maps to optimize them)? Because if not, you're depending on undefined behavior.

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.

No, it is necessary in all cases. Look at the InstCombine code I linked in a sibling comment…

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/...

Or maybe another way to put it would be that the given language is hardware-antagonistic.

Reply on news.ycombinator.com