I can imagine having a lot of fun making a toy compiler that emits LLVM IR directly.
Well, I'm still plugging away at the Deca compiler that outputs to LLVM IR directly. It's loads of fun!
Practically speaking, is there a good reason to do this in non-toy software rather than the more-or-less standard practice of using C as an IR?
I can tell you why I use it:
* Even through the C interface, I have an actual library API that outputs the IR code directly rather than having to transform my syntax trees into C syntax trees and then output through a C parser library.
* You recursively walk your syntax tree passing an LLVMInstructionBuilder* around to different instruction functions in the API. The result is that your code is a recursive tree-walk (rather than an ordered tree-walk), and the builder object serializes it all for you (including using one instruction's output as input to another) according to the natural order of evaluation in your higher-level language.
Well, I'm still plugging away at the Deca compiler that outputs to LLVM IR directly. It's loads of fun!
Practically speaking, is there a good reason to do this in non-toy software rather than the more-or-less standard practice of using C as an IR?
I can tell you why I use it:
* Even through the C interface, I have an actual library API that outputs the IR code directly rather than having to transform my syntax trees into C syntax trees and then output through a C parser library.
* You recursively walk your syntax tree passing an LLVMInstructionBuilder* around to different instruction functions in the API. The result is that your code is a recursive tree-walk (rather than an ordered tree-walk), and the builder object serializes it all for you (including using one instruction's output as input to another) according to the natural order of evaluation in your higher-level language.