A Tourist’s Guide to the LLVM Source Code

This is from years ago, mind, but my recollection of the pain points were:

- enormously steep learning curve; very little of this layer is documented and there's a lot of concepts hidden behind layers of abstractions hidden behind other layers of abstractions, all of which you need to understand, but they're all cyclic. There's nowhere to start; everything you look at depends on your understanding of something else.

- very hard to debug --- the compiler's main reaction to things going wrong is to seg fault, which requires debugging through compiler internals (and understanding the compiler internals) to fix.

- holes in the tools. After generating the IR node tree, the main piece of machinery in the compiler is a pattern matcher which finds machine code instructions for sets of nodes in the tree. This is automatically generated by tablegen, but there are some patterns that it can't match, which means that along with the tablegen matcher you also need to write a manual matcher in C++ for the other patterns, which is very verbose and difficult to keep track of. Also, the tablegen matcher is pretty brittle and has a tendency to either hang or match the wrong pattern if you don't get it just right. Understanding why it's doing what it's doing is non-trivial.

The main problem, though, is that the pool of knowledge of how to write targets is restricted to a very small number of people --- it's all what an ex-boss of mine used to refer to as 'tribal knowledge'. So that when you run into a problem, you're reliant on finding one of these people who has enough time or incentive to help. Since the problems you run into tend to be complex, helping is hard, so getting good help isn't easy, and so on.

I should add that gcc suffers from exactly the same set of problems, except possibly a little more so. gcc's get better target layer documentation, but the LLVM community is much more helpful; gcc is simpler, but LLVM I think has the edge of good design. They're both much of a muchness.

It's frustrating, as compiler backends aren't that hard. There should be a compiler somewhere which combines easy porting with adequate code generation[1], for people who don't want to spend the resources needed for an LLVM or gcc port.

[1] I'm actually working on this.

An example of this is branch delay slots. Some RISCs have these. With a branch delay slot, the instruction after a branch is unconditionally executed, which lets the processor pipeline the branch efficiently. You need to tweak your codegen so that some earlier instruction will get delayed till the branch slot if you want to make full use of your CPU cycles.

Each target arch has its own quirks when it comes to stuff like this, and there's a different way to write efficient code for each. So it's not correct that optimizations have already been done.

(This is not necessarily the reason why tablegen is hard, it's just another factor)

... but also because the LLVM framework is very generic. This is both a blessing and a challenge. You can implement a new target by writing much less code (due to those TableGen files), but this code will be trickier since you have to grok several generic metaprogramming mechanisms.

Because of this, enabling a new backend is a substantial amount of work even if the instruction selection/generation is indeed taken care of for you.

Well, mostly. I do read some percentage of the articles and comments as I go, and I do go back to see updates to the comments... and to, every once in awhile, read the fave'd article.

I feel like I ought to have a side project that uses my HN favorites, pinboard links, comments, etc to seed a recommendation engine of 'other stuff you should probably read'.

Any particular style grows on you with time. It's more important to make sure the code is internally consistent.