Target: the processor-specific parts of the backends live here. There are lots of TableGen files. As far as I can tell, you create a new LLVM backend by cloning the one for the architecture that looks the most like yours and then beating on it for a couple of years.
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.
https://github.com/christinaa/LLVM-VideoCore4
It's not entirely finished, but it's good enough to get real work done if you're careful.
Previous HN thread:
Anything to share yet? Will it take LLVM IR as input or are you targeting a specific language? I'm very interested. So far, I found only the Plan 9 C compilers seemed to have relatively straightforward code as it was designed for this.
It's not actually based on LLVM at all; I'm working with a completely different (and simpler) compiler suite, albeit using some of the same principles. The code quality is never going to be good, but I'm hoping the end result will allow a compiler port to any random relatively sane architecture in only two source files.
Have you looked into PBQP register allocation? It's almost as simple as basic graph coloring but handles irregularities in a nice and disciplined way.
There is also an ILP one, which is only useful for comparison.
It's designed to be simpler. One user told me it already compiles their project 4x faster than GCC with estimated speed between 01 and 02 despite so few lines of code. If it's backends are easier, might be a selling point on top of simplicity.
... 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.
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)
> ObjectYAML seems to support encoding object files as YAML. I do not know why this is desirable.
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.