A while back I got about half of an LLVM backend for the VideoCore IV done (since completed by someone else). I eventually ground to a halt due to intractable bugs; later, someone picked it up and completed it.
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.
> There should be a compiler somewhere which combines easy porting with adequate code generation[1]
> [1] I'm actually working on this.
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.
I have mostly-working code --- but the register allocator I was using turns out to be pretty pants, so it's generating lousy code and is nowhere ready to look at yet. I'm taking time off to learn about graph colouring to try and do a proper job. (Turns out graph colouring on irregular architectures is kinda exciting, and not in a good way.)
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.
I helped building the one in libfirm and I agree. The x86 architecture is quite regular and we have not used it for others in practice. However, for all irregularities I have come across I could immediately see how to model it in theory.
The Plan 9 C compilers are nice as they're so small. Still, the backend creation process would look roughly similar, at least from where I'm standing: copy a roughly similar one and beat on it for some time. The difference is in duration, though. You're unlikely to pound on it for several years until you get something working.
Who completed it and is it in an usable state? I have seen the GCC port used for the open firmware project but regarding LLVM I only found a QPU backend used by Simon for the Raspberry Pi Quake challenge.
Ahh thanks, that's what they used before switching over to GCC (Which seems to be also based on your first steps ;-)). Great work btw! It's kinda annoying that they didn't release at least an instruction set documentation yet.
As someone who's aiming to write an lx106 backend, thanks for the writeup and for the warning. I'll now think twice (and brace for a real challenge) before starting it.
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.
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.