Hacker News Reader

Comment by msla | Hacker News Reader

When you emit C, you're limited by C, at least if you want to emit C as opposed to inline assembly wrapped in C. For example, it's harder to have a function return more than one value in C than it is in most architectures, you can't do things with processor flags (on architectures which have them), you're at the mercy of the C compiler's optimizer as to vectorization and loop unrolling, you can't always preserve semantic information in the source code even when a "reasonable" compiler would be able to use it to improve the machine code...

LLVM was created to replace emitting C, by providing programmers a way to turn source code into a representation that is lower-level than C without having to write the whole optimization and assembly code generation pipeline.

View on HN

I think we can all agree that LLVM IR is a more powerful compilation target than C. However, what Pizlo was saying is that generating C can be simpler than generating LLVM IR. A bunch of printfs can get you very far.

There are very few things that you can say in LLVM IR that you can't say in C.

Except for _e.g._ memory alignment, or types of a given width (until C99).

For lots of us the extensions that gcc and clang support are part of C. So, a backend that emits C would get access to those things if it wanted.

Until you want to write code that works on platforms not supported by these compilers.

How many platforms does LLVM support that Clang does not?

I use C as a target for my own compiler and I agree that there are very few things that I miss. But the ones we do miss do stick out like a sore thumb. One of the main ones for me is a way to get an accurate stack map for precise garbage collection. With C you usually gotta go for a conservative GC, or you need to maintain a shadow stack. (Although I'll admit that the GC story with LLVM isn't super great either)

LLVM while a very successful project isn't nothing new as idea.

IBM had several LLVM like projects during the 70's, and that is how their surviving IBM i and z/OS work anyway, with language environments that AOT at installation time.

Likewise there were projects like Amsterdam Compiler Kit among others during the early 80's.

> it's harder to have a function return more than one value in C than it is in most architectures

Biggest issue is the cultural aversion to returning structs and tagged unions.

And it's not even hard, just ugly. Which is much less of a problem for a compiler IR.

That’s true. If you’re doing a lot of that then llvm ir might be nicer. Matter of taste of course.

Some syntactic sugar using anonymous structs and type inference would probably fix the ugly.

Reply on news.ycombinator.com