Hacker News Reader

Comment by catpolice | Hacker News Reader

> LLVM is smaller at 1.6 million lines, but is newer, supports only C and C++ by default

Unless I'm misunderstanding "by default", this isn't true. LLVM is language agnostic and supports many languages - even the primary C-like frontend Clang supports more than just C/C++.

View on HN

We have worked with LLVM a lot for own own compilers and DSPs.

LLVM Intermediate representation in practice is C++, AST is C++. LLVM do not support many languages,many languages support LLVM, which is different.

That is many people, or languages' designers, have made the necessary work to make their languages compatible with LLVM IR. If the language is similar to C++, this is a simple task, if it is very different, it is very hard.

LLVM does not support other languages, in fact, codebase changes a lot making maintenance painful.

Could you elaborate on the C++ resemblance?

Specifically, in my limited experience LLVM IR resembles typical hardware rather than C++. Modeling the hardware is a design goal for C++, of course, so anything hardware-like must be C++-like. Can you describe some ways in which IR resembles C++ that are not plausible ways to resemble hardware? I'm really curious.

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

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.

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.

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

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.

LLVM is targeted by both Haskell and Idris - two of the most un-C/C++-like languages I've ever come across.

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

Note that mentioned LLVM patches are now upstream. http://llvm.org/docs/LangRef.html#calling-conventions documents "GHC convention", for example.

Perhaps they mean that within those 1.6 million lines, the only frontend is Clang? But the line count for gcc includes e.g. gfortran as well?

The GCC addons (gcc-fortran, gcc-cobal, and gcc-go) just convert the existing language into C that is just ingested into the standard GCC. It was only around 2008 that gcc-c++ stopped doing the internal translation/name mangling dance and gained native first party support [1].

Much like how the older versions of GCC used to just produce ASM files to be ingested into GAS to create the binary objects.

[1] https://lwn.net/Articles/542457/

The link you posted has nothing to do with how GCC does codegen. It is about GCC transitioning itself from being written in C to being written in C++.

GCC IR is not C

Yeah, I thought that part of the point of the LLVM project was that front end language compilers (entirely language agnostic) could target non-platform specific LLVM IR code, and then let the backend LLVM compiler compile to multiple backend targets. It simplifies front-end compiler development by having a single IR target over multiple native target.

You are correct. The article is misinformed

Reply on news.ycombinator.com