Ask HN: LLVM vs. C?
What does LLVM have that can not be achieved 1 to 1 in C? And what does C have that can not be reproduced 1 to 1 in LLVM?
And when I say C I mean tcc, sdcc, gcc, clang and other C compilers.
It feels to me like C should be superior to LLVM and allow to do anything that is possible to do with LLVM, but maybe I'm wrong? (asking about it due to all that "fuzz-buzz" about zig going for C as its main target)
Would appreciate real down to the ground answers, not a sense of how things work or generalizations - as that will introduce unnecessary noise in judgement of comparison.
40 comments
[ 3.0 ms ] story [ 103 ms ] threadGives some good reasons. I just searched for LLVM vs C.
As I see it: LLVM is like a universal remote. It is a quasi-assembly representation that can then be further compiled to multiple architectures. If you target LLVM, then you can compile to anything that LLVM can compile to. To support additional architectures, then all that needs to happen is for that architecture to work with LLVM, and then every project that uses LLVM will now support that architecture.
C, on the other hand, relies on a compiler. Because a compiler may be specifically designed for one architecture, then it may (although it is not guaranteed) generate better binaries than LLVM.
Because C can be compiled using clang, which uses LLVM, then there is nothing that C can do that LLVM cannot.
It may, however, be possible to produce opcode sequences using LLVM that is not possible in C, since C imposes semantics and structure on a program (syntax).
Lastly, it may be a simple question of resources. Is it easier to find people who know C, or people who know LLVM? Is it easier to set up a toolchain that compiles C, or one that compiles LLVM? Historically speaking, which one has been around longer? (C, of course.) Do the semantics of the source language closely match the available C paradigms? Which is more stable?
I also "incorrectly" wrote "target C" instead of "target C code". It's obvious what I meant.
>> Comparing the 2 is nonsensical to say the least.
You could have easily googled "C vs LLVM as a backend" to find a lot of interesting discussions comparing both before being so confidently incorrect
https://news.ycombinator.com/item?id=36529456
Basically the Zig language is moving away from using LLVM in its backend. One backend they are adding is one that generates C.
I guess if I had to restate the OP’s question, I would say:
What are the trade offs in making a compiler target LLVM versus C in its backend.
Ie, linkage[0], lifetime[1], and ordering[2] information can be critical to delivering performance.
Now that said, GCC is _pretty damned amazing_ at squeezing out this information from C, and it's available for use just about everywhere. But it's good at figuring it out for _hand-written_ C. The sort of C that's generated as a compilation output from other languages, like Chicken Scheme and Nim, may not be written in a way that allows the C compiler to fully take advantage of its optimization abilities.
What I find with generated C is that it often is prone to blowing the stack or missing cache far more than hand-written C would. There's often something funky happening (Cheney-on-the-MTA) or it's a soup of function pointers and object references scattered haphazardly across memory.
0: https://llvm.org/docs/LangRef.html#linkage-types
1: https://llvm.org/docs/LangRef.html#object-lifetime
2: https://llvm.org/docs/LangRef.html#memory-model-for-concurre...
Definitely a possibility. Nim does pretty well since it has concepts of stack values in addition to ref's unlike perhaps Chicken Scheme or others. Add in that the Nim compiler can do some large scale optimizations that are hard to do in had written C it can perform as well (or better!) than C with some work. Though it's easy to loose performance too if you're sloppy.
C is very easy to get started with if you don't already know LLVM. You don't have to flatten everything to SSA + basic blocks and can keep expressions as trees. The downside is that once your compiler is reasonably complete, you may spend quite a bit of time working around quirks of C (e.g. int promotion is very annoying when you already have full type information, so your compiler either has to understand C semantics fairly well or defensively cast every subexpression).
I have a C backend in my compiler (https://github.com/alumina-lang/alumina) and it works really well, though the generated C is really ugly and assembly-like. With #line directives, you can also get source-level debugging (gdb/lldb) that just works out of the box.
There are a few goodies that LLVM gives you that you don't get with C, like coverage (https://clang.llvm.org/docs/SourceBasedCodeCoverage.html). It works when done through clang, but cannot easily be made to track the original sources.
Do you want to have signed integer overflow not be undefined behavior? Sorry, you can't do that in C. Do you want to support SIMD vector types? Oops, no support in C. Underaligned memory accesses? Packed structures? Support for handling unwind structures? Coroutines?
> It feels to me like C should be superior to LLVM and allow to do anything that is possible to do with LLVM, but maybe I'm wrong?
Very much the inverse: as LLVM is used to implement a C compiler, LLVM can faithfully reproduce all of the C semantics, but C cannot be used to implement all of the LLVM features. Even if you pretend C doesn't have undefined behavior, and even if you include compiler extensions as part of C, there are still a few LLVM instructions and intrinsics that just don't exist in C (chief among them is invoke, which is used to implement C++ exception handling).
https://github.com/JuliaHubOSS/llvm-cbe
You can get those things with most C compilers via compiler flags or other extensions.
You can handle unwinding by targeting C++ instead of C, or doing the unwinding in a totally custom way. The last JVM I wrote had a C backend that did unwinding. It worked with any C compiler. You wouldn’t want to use llvm’s unwinding for the unwinding of most higher level languages anyway.
Coroutines can be lowered to C. Most coroutines in higher level languages work best when lowered to C-like functions that save/restore state as needed. Heck, JSC’s coroutines just lower to JSC’s internal notion of a regular function.
> there are still a few LLVM instructions and intrinsics that just don't exist in C (chief among them is invoke, which is used to implement C++ exception handling).
Right so if you’re implementing C++ then you probably want to compile to llvm not C. But if you have exception semantics that are sufficiently not like C++ then you’re better off handling them at a higher level and lowering to something that doesn’t rely on invoke. You can do that in C.
More details: C++ exceptions and llvm invoke are optimized very aggressively for the case that no exceptions are thrown. If you compile Java, where some programs use exceptions for control flow, you’ll want an implementation that is less aggressively optimized for not throwing. And then if you do that then C is fine.
I think these are supported through intrinsics, for example:
https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
But I suppose they are not considered standard C.
If you write a compiler that targets C, you can have that. ‘Just’ generate code that avoids it. If you want it to wrap around, for example, generate something like this (I’m not 100% sure it’s right)):
instead of If you want that to trap on overflow, the code gets more convoluted (see e.g. https://codereview.stackexchange.com/a/37178 for what’s needed to detect overflow)Packed structures and unaligned data similarly can be supported by generating C code that manipulates char arrays instead of C structs.
I wouldn’t count on having any C compiler generate efficient code for it, though.
That applies to most of the other features, too. You can have garbage collection, exception handling and coroutines, for example, but if you generate C code implementing it, chances are zero that the C compiler turns that into efficient code.
As for specific features, for example function and parameter attributes[1][2] generally are not directly accessible in ISO C. You also have bit easier time controlling FP ops[3]; in ISO C they are annoyingly underdefined imho. For integers you have arbitrary width integer types (i42 is valid type in llvm, not expressible in C). For both you also have first-class vector types[4], while ISO C is afaik completely blind to vectorization.
That is just scratching the surface here. C doesn't really map anymore nicely to all the low-level intricacies we have these days like it did in the K&R days.
[1] https://llvm.org/docs/LangRef.html#function-attributes
[2] https://llvm.org/docs/LangRef.html#parameter-attributes
[3] https://llvm.org/docs/LangRef.html#floating-point-environmen...
[4] https://llvm.org/docs/LangRef.html#vector-type
Otherwise it's hard to really compare them in any reasonable way. Maybe you have something in mind, but currently the question reads like you don't understand very well what llmv is. (I'd recommend searching / reading on that topic first if that's the case)
For instance exception handling (used for C++), operations with checks for overflow (used by both Swift and Rust, I suspect), and arithmetic with integers smaller than an "int" (also, Swift and Rust).
I think LLVM also has explicit support for coroutines and multi-entry functions.
If your language needs any of those features, implementing any of those on top of C could be difficult to get right and would probably not perform as well.
But if you're asking the advantage of targeting LLVM directly as opposed to targeting C then the answer is that you don't have to implement everything in terms of C's semantics, compilation model, and memory model. While you probably can the question is should you, and what that costs in terms of optimizations left on the table.
Some examples are the strict aliasing model, support for generators out of the box with blockaddr, guaranteed tail call optimization via specialized calling conventions, zero cost exception handling, and so on.
That's not even getting into some of the annoying stuff that you as a language author will probably care about at some point, like relying on glibc.
Another downside of C is that to use C as a backend well, you’ll have to rely on nonstandard compiler flags like -fwrapv and -fno-strict-aliasing (among others). I don’t think this is actually a downside of C, since support for those flags (or their equivalents) is widespread.
Another downside of C is that there will be a few intrinsics or other weird features you won’t get. But it’s not clear to me that those make enough of a difference to matter.
You could argue that a downside of C is that you won’t be able to easily add debugging support that way. But llvm’s support for debug info is so bad (it’s hella inaccurate) that I’m not sure this is a real downside of C.
A major upside of C is that there are more diverse backends for C than for llvm IR.
Another major advantage of C is that with a modicum of care you can make your backend produce readable and hackable C code. This speeds up the debugging process greatly. (And by debugging I mean debugging your language implementation, not users of your implementation debugging their programs.)
So, if I was implementing an AOT language today, my first cut would be a C backend and my second cut would be a custom backend. So, I would do what Zig is doing.
The downside is that your frontend pretty much has to be written in C++ (or you maintain your own bridging wrapper library like Rust does).
For a hobby project, go with whatever is easiest. If you’re a C++ programmer and don’t mind writing your frontend in C++, take a look at LLVM. Writing an interpreter is also a valid choice. You can still learn a lot about compiler design by targeting a suitable bytecode format instead of a real CPU.
Production compilers these days either target the LLVM C++ API or have their own code generation backend.
This little distinction makes all the difference in terms of immediate utility, because in practical usage, languages tend to be libraries with the language attached, rather than the converse.
To be a serious replacement to C, Zig had to resolve this question about what a standard library should look like going forward, and across more exotic targets like WebAssembly. They made some thoughtful choices, more than I can summarize(especially since I haven't followed the project in a while).
When your language is "compile to C" you get stdlib for free...and you have to deal with cross-platform behavior in a C-like way forevermore. And this is a huge hindrance because it means your build system is now in the 1970's, and anything you accrete upon it eventually gets dragged back there because a user wants to get some Big Important Library compiling and nobody is on the same page about how to do that.
If you target LLVM you get compiler infrastructure, but also options about what you want the overall experience to look like, which can include C header compatibility, or something else. It's more feasible to achieve a thoughtful design like what Zig does.
You don't control aliasing info beyond C's minimum. You don't get true immutability, since C's const allows its target to be mutated from elsewhere.
You don't control what happens before main(). You don't get static constructors, unless you use C++.
You have almost no control over debug information.
You have very little control over inlining.
You don't control calling conventions. You can't control alignment.
There's a bit more you can do if you use non-standard C extensions, but generally you'll always be an abstraction layer away from the code you want to generate, and have your language's semantics tainted by C's semantics.
FWIW, const restrict pointers in C do enforce true immutability: if an object is ever read from such a pointer (or another pointer based on it), then nothing can have modified that object since the pointer's corresponding block began, and nothing can later modify that object until the pointer's block ends. Otherwise, UB occurs.
Targeting C in current year doesn't make sense when Zig and C++ are available.
Don't forget JVM or BEAM.
LLVM is an open source modular complier system. There are three main pieces:
The Front-end. This is a part that reads in your source code files and generates any syntax errors. Clang is an example of a front end. The front end produces IR or "Internal Representation" which is consumed by the other parts of the compiler.
The optimizer. Pretty self explanatory. The optimizer takes in IR and (ideally) moves stuff around some that the final executable runs faster.
The backend. This is where the magic really happens. The backend takes in IR and produces that sweet sweet machine code that we're really after.
The benefit to zig of using LLVM is that they only have to write/maintain a Frontend. I don't think gcc and other C/C++ compliers where quite designed for modularity like LLVM was so building a new front end for them is difficult compared to LLVM.
Eventually, your language will benefit from adding a "middle end" and MLIR is the best choice for building that today (and it's likely to remain so for the foreseeable future, since there's very little competition and it has a ton of momentum). It handles infrastructure-level middle-end stuff that it's difficult to improve upon, so you'd just waste dev hours reimplementing boilerplate stuff yourself.
Before you build a middle end for your language, you can just target MLIR's LLVM IR dialect and you'll be around a dozen lines of code away from compiling with LLVM and invoking LLVM's JIT. So it's basically cost-free to target MLIR today and have an easy path to incrementally defining a new dialect for your middle end when it becomes profitable to do so.
[0] A good reason to not target MLIR is you are targeting an existing runtime like the JVM or CLR, or writing a transpiler to some existing language (e.g. JavaScript). Since you mentioned C as an option, this wouldn't apply to you.
[1] MLIR is part of the larger LLVM project.