6 ms·

Ha, was just reading http://aosabook.org/en/llvm.html http://aosabook.org/en/llvm.html. (Really like that LLVM IR. Does anyone code in it directly? Was also th

Ha, was just reading http://aosabook.org/en/llvm.html http://aosabook.org/en/llvm.html. (Really like that LLVM IR. Does anyone code in it directly? Was also thinking it would be interesting to port Knuth's MMIX examples to it.)

falcolas 10y ago
If I recall correctly, the textual IR is unstable between releases. They recommend building ASTs with their APIs instead.
- rwallace 10y ago
  I was under the impression the API is also unstable between releases. Has the API broken less often than the text format over the last few releases?
  - sanxiyn 10y ago
    Yes. Quotes from LLVM Developer Policy http://llvm.org/docs/DeveloperPolicy.html http://llvm.org/docs/DeveloperPolicy.html On text format: "The textual format is not backwards compatible. We don't change it too often, but there are no specific promises." On C API: "The C API is, in general, a "best effort" for stability. This means that we make every attempt to keep the C API stable, but that stability will be limited by the abstractness of the interface and the stability of the C++ API that it wraps." There is confusion because C++ API is unstable (very unstable). But C API is stable. And C API is more stable than text format. (In my experience, policy is accurate description of actual practice and not empty promise.)
    - rwallace 10y ago
      Ah! I was under the impression that the C API was quasi-deprecated relative to the C++ API, but from what you're saying, it sounds like that's not the case?
witty_username 10y ago
Coding directly in LLVM IR is tedious. It's supposed to be used via the AST building APIs.
- CalChris 10y ago
  IR is better than assembly It's a bit of a thought experiment but it's not totally insane. Let's just say that humanoids writing in IR makes more sense than humanoids writing in asm.js Ultimately, IR is an assembly language. By contrast, web assembly is not an assembly language. https://idea.popcount.org/2013-07-24-ir-is-better-than-assembly/ https://idea.popcount.org/2013-07-24-ir-is-better-than-assem...
roninb 10y ago
The way I understand it, in the near future, the folk who write languages/compilers/build toolkits will be writing down to LLVM's Intermediate Representation rather than down to some specific machine code for some specific chipset. Then the folk whom build the processors/architecture/assembly languages (and open source advocates when businesses ultimately ignore LLVM for a bit) will be writing the conversion from IR down to some specific machine code. This allows Intel to convert the IR line "COMPLICATEDFUNCTION $r2 5" to some advanced x86 call that has some significant speed or memory increase and is only one line while TI can still call the 26 lines of MIPS they need to call and both will be semantically equivalent. That way you can, from the the software side, be relatively agnostic with how you're writing code and the chipset side is able to get every ounce of optimization using advanced functionality (if available). More importantly, software side is then able to ignore any processor features (be they speed ups or slowdowns) because every chipset manufacturer should have some toolset to convert your IR down to the best machine code they've got based on some desires (speed, space, power, etc). Inevitably, there will still be differences in performance between chipsets but being able to build down to IR (even with performance issues for some chipsets while everyone gets on board) and not some large set of assembly languages should be very nice.
- pjmlp 10y ago
  Just as additional information, this is just the future catching up with the past. Most mainframe architectures since the early 60's, didn't really used pure Assembly, rather bytecodes that were processed by microcode on the CPUs. Hence why many old papers tend to mix both terms, bytecodes vs assembly. This tradition carried on to mainframe architectures like the AS/400, nowadays IBM i, where the user space is pure bytecode (even C), called TIMI, and a kernel level JIT is used at installation time to convert the application into the actual machine code. IBM i Java takes advantage of this, where the JVM bytecodes are converted into TIMI bytecodes. It also provides some kind of common language runtime called ILE (Integrated Language Environment). So the trend of using LLVM bitcode on iDevices, Dalvik on Android or MSIL on .NET, JavaScript/WebAssembly on browsers, is similarly with containers, modern computing catching up with mainframe ideas.
  - 10y ago
andrewvijay 10y ago
wow thanks for that link! Lots of goodies.
mhh__ 10y ago
Nobody actually programs in the IR of a compiler, except for (say) tests and debugging. The IR is not usually designed to be read to by humans, although LLVM is actually very readable (But still rather tedious). If you looked at, just for an example, the IR used in the dmd d compiler, using (Walter Bright's) Digital Mars backend then you'd notice that the IR is not trivial to access at all. Last time I checked, you had to actually dive into the backend code (I'm pretty sure there's an undocumented flag/switch that I'm missing somewhere) to get the IR out of the compiler. In fairly sharp contrast to this, getting the IR (in a textual format!) is normally as simple as using -emit-llvm when compiling. This is part of the revolution (~Slight~ exaggeration) that LLVM brought about in compiler design: Compared to most other compilers, LLVM is designed to be very portable. The only compiler, of similar stature, like it is GCC. GCC is much better than it was, I'd imagine because of the competition from LLVM/Clang. Tangent Aside: The LLVM IR textual format is not guaranteed to be stable at all. It's also not particularly nice to program in, and also it uses SSA form so it's not suitable for humane consumption. It looks like a high level programming language, but it really isn't. IR is designed to be generated, bullied and discard by the compiler. If you want to punish yourself, the LLVM project does contain interpreters and compilers just for IR in a file. If I remember correctly, Clang will compile anything with a ?.ll? file as IR. You can see all the optimisation passes in action here: https://godbolt.org/g/uZH3UD https://godbolt.org/g/uZH3UD
- nickpsecurity 10y ago
  "Nobody actually programs in the IR of a compiler" It's called LISP. It is a niche style, I'll give you. ;)
  - mhh__ 10y ago
    :-). I think GCC has/had IR's that are LISP like.
- makomk 10y ago
  Parts of the libraries for the Clover OpenCL implementation seem to be programmed in LLVM IR directly.

falcolas 10y ago

If I recall correctly, the textual IR is unstable between releases. They recommend building ASTs with their APIs instead.

rwallace 10y ago
I was under the impression the API is also unstable between releases. Has the API broken less often than the text format over the last few releases?
- sanxiyn 10y ago
  Yes. Quotes from LLVM Developer Policy http://llvm.org/docs/DeveloperPolicy.html http://llvm.org/docs/DeveloperPolicy.html On text format: "The textual format is not backwards compatible. We don't change it too often, but there are no specific promises." On C API: "The C API is, in general, a "best effort" for stability. This means that we make every attempt to keep the C API stable, but that stability will be limited by the abstractness of the interface and the stability of the C++ API that it wraps." There is confusion because C++ API is unstable (very unstable). But C API is stable. And C API is more stable than text format. (In my experience, policy is accurate description of actual practice and not empty promise.)
  - rwallace 10y ago
    Ah! I was under the impression that the C API was quasi-deprecated relative to the C++ API, but from what you're saying, it sounds like that's not the case?

witty_username 10y ago

Coding directly in LLVM IR is tedious. It's supposed to be used via the AST building APIs.

CalChris 10y ago
IR is better than assembly It's a bit of a thought experiment but it's not totally insane. Let's just say that humanoids writing in IR makes more sense than humanoids writing in asm.js Ultimately, IR is an assembly language. By contrast, web assembly is not an assembly language. https://idea.popcount.org/2013-07-24-ir-is-better-than-assembly/ https://idea.popcount.org/2013-07-24-ir-is-better-than-assem...

roninb 10y ago

The way I understand it, in the near future, the folk who write languages/compilers/build toolkits will be writing down to LLVM's Intermediate Representation rather than down to some specific machine code for some specific chipset. Then the folk whom build the processors/architecture/assembly languages (and open source advocates when businesses ultimately ignore LLVM for a bit) will be writing the conversion from IR down to some specific machine code. This allows Intel to convert the IR line "COMPLICATEDFUNCTION $r2 5" to some advanced x86 call that has some significant speed or memory increase and is only one line while TI can still call the 26 lines of MIPS they need to call and both will be semantically equivalent. That way you can, from the the software side, be relatively agnostic with how you're writing code and the chipset side is able to get every ounce of optimization using advanced functionality (if available). More importantly, software side is then able to ignore any processor features (be they speed ups or slowdowns) because every chipset manufacturer should have some toolset to convert your IR down to the best machine code they've got based on some desires (speed, space, power, etc). Inevitably, there will still be differences in performance between chipsets but being able to build down to IR (even with performance issues for some chipsets while everyone gets on board) and not some large set of assembly languages should be very nice.

pjmlp 10y ago
Just as additional information, this is just the future catching up with the past. Most mainframe architectures since the early 60's, didn't really used pure Assembly, rather bytecodes that were processed by microcode on the CPUs. Hence why many old papers tend to mix both terms, bytecodes vs assembly. This tradition carried on to mainframe architectures like the AS/400, nowadays IBM i, where the user space is pure bytecode (even C), called TIMI, and a kernel level JIT is used at installation time to convert the application into the actual machine code. IBM i Java takes advantage of this, where the JVM bytecodes are converted into TIMI bytecodes. It also provides some kind of common language runtime called ILE (Integrated Language Environment). So the trend of using LLVM bitcode on iDevices, Dalvik on Android or MSIL on .NET, JavaScript/WebAssembly on browsers, is similarly with containers, modern computing catching up with mainframe ideas.
- 10y ago

andrewvijay 10y ago

wow thanks for that link! Lots of goodies.

mhh__ 10y ago

Nobody actually programs in the IR of a compiler, except for (say) tests and debugging. The IR is not usually designed to be read to by humans, although LLVM is actually very readable (But still rather tedious). If you looked at, just for an example, the IR used in the dmd d compiler, using (Walter Bright's) Digital Mars backend then you'd notice that the IR is not trivial to access at all. Last time I checked, you had to actually dive into the backend code (I'm pretty sure there's an undocumented flag/switch that I'm missing somewhere) to get the IR out of the compiler. In fairly sharp contrast to this, getting the IR (in a textual format!) is normally as simple as using -emit-llvm when compiling. This is part of the revolution (~Slight~ exaggeration) that LLVM brought about in compiler design: Compared to most other compilers, LLVM is designed to be very portable. The only compiler, of similar stature, like it is GCC. GCC is much better than it was, I'd imagine because of the competition from LLVM/Clang. Tangent Aside: The LLVM IR textual format is not guaranteed to be stable at all. It's also not particularly nice to program in, and also it uses SSA form so it's not suitable for humane consumption. It looks like a high level programming language, but it really isn't. IR is designed to be generated, bullied and discard by the compiler. If you want to punish yourself, the LLVM project does contain interpreters and compilers just for IR in a file. If I remember correctly, Clang will compile anything with a ?.ll? file as IR. You can see all the optimisation passes in action here: https://godbolt.org/g/uZH3UD https://godbolt.org/g/uZH3UD

nickpsecurity 10y ago
"Nobody actually programs in the IR of a compiler" It's called LISP. It is a niche style, I'll give you. ;)
- mhh__ 10y ago
  :-). I think GCC has/had IR's that are LISP like.
makomk 10y ago
Parts of the libraries for the Clover OpenCL implementation seem to be programmed in LLVM IR directly.