4 ms·

Awesome overview! The author threw a hilarious quip in at the end too: Target: the processor-specific parts of the backends live here. There are lots of TableG

Awesome overview! The author threw a hilarious quip in at the end too: 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.

gravypod 10y ago
I've heard this many times that llvm targets are really hard to do. I don't really understand why. The code has already been parsed, optimized, and cleaned into a presumably clean format. What is the issue? Is the framework provided by llvm just crappy?
- david-given 10y ago
  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. [1] I'm actually working on this.
  - kosma 10y ago
    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.
  - bootloop 10y ago
    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.
    - david-given 10y ago
      Christina Brooks: https://github.com/christinaa/LLVM-VideoCore4 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: https://news.ycombinator.com/item?id=11612449 https://news.ycombinator.com/item?id=11612449
      - bootloop 10y ago
        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.
  - speps 10y ago
    > 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.
    - slrz 10y ago
      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.
- eliben 10y ago
  Because emitting efficient target machine code is a non-trivial problem? ... 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.
- Manishearth 10y ago
  It's not been "already optimized". The kind of machine language affects optimizations too. 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)
piokuc 10y ago
The beauty of LLVM is that developers of compilers based on LLVM like Pony or Julia don't have to even think about the backends.
- obl 10y ago
  Unfortunately that's only superficially true. You have to care about GC interop, unwind & debug dwarf data, implementing part of the ABI in the frontend, and of course the occasional bugs when you exercise code path that clang does not. 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.
  - piokuc 10y ago
    Sounds like you have some practical experience with that. What frontend was it? Are these problems frontend/language independent?
- pjmlp 10y ago
  Same applies to JVM and CLR.
Others 10y ago
This quip is also quite funny: > ObjectYAML seems to support encoding object files as YAML. I do not know why this is desirable.

gravypod 10y ago

I've heard this many times that llvm targets are really hard to do. I don't really understand why. The code has already been parsed, optimized, and cleaned into a presumably clean format. What is the issue? Is the framework provided by llvm just crappy?

david-given 10y ago
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. [1] I'm actually working on this.
- kosma 10y ago
  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.
- bootloop 10y ago
  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.
  - david-given 10y ago
    Christina Brooks: https://github.com/christinaa/LLVM-VideoCore4 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: https://news.ycombinator.com/item?id=11612449 https://news.ycombinator.com/item?id=11612449
    - bootloop 10y ago
      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.
- speps 10y ago
  > 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.
  - slrz 10y ago
    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.
eliben 10y ago
Because emitting efficient target machine code is a non-trivial problem? ... 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.
Manishearth 10y ago
It's not been "already optimized". The kind of machine language affects optimizations too. 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)

piokuc 10y ago

The beauty of LLVM is that developers of compilers based on LLVM like Pony or Julia don't have to even think about the backends.

obl 10y ago
Unfortunately that's only superficially true. You have to care about GC interop, unwind & debug dwarf data, implementing part of the ABI in the frontend, and of course the occasional bugs when you exercise code path that clang does not. 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.
- piokuc 10y ago
  Sounds like you have some practical experience with that. What frontend was it? Are these problems frontend/language independent?
pjmlp 10y ago
Same applies to JVM and CLR.

Others 10y ago

This quip is also quite funny: > ObjectYAML seems to support encoding object files as YAML. I do not know why this is desirable.