4 ms·

Most of the guides I've seen for LLVM recommend you use the LLVM libs to generate the IR. Why? I feel like it would be much easier to generate the IR directly l

Most of the guides I've seen for LLVM recommend you use the LLVM libs to generate the IR. Why? I feel like it would be much easier to generate the IR directly like the author has done. It also wouldn't tie me to any particular library - I think the only actively maintained one is the C++ one.

hawkice 10y ago
Presumably because it allows a workflow that skips over parsing (and possibly error prone generating code). Also allows generators to e.g. lint things without a bananas workflow.
achamayou 10y ago
Because LLVM makes no guarantees about IR compatibility between releases. With the API at least, your compiler can catch the larger breaks when you upgrade, and they're likely to come with more doc/comments and change notes than the IR tweaks.
- nhaehnle 10y ago
  To be more precise, there is no guarantee at all about textual IR compatibility. Compatibility of bitcode, which is a binary representation of IR, is meant to be preserved across a very generous range of LLVM releases (but not forever).
legulere 10y ago
The IR is highly unstable, especially the text representation, which is basically just a debugging tool. The bitcode format is rather complicated, but at least there is backwards compatibility. LLVM is the library, so you are bound to it anyway. Further by having code for emiting IR you are basically just copying functionality that already exists.
- zzzcpan 10y ago
  You can make a perfectly stable IR from that Kaleidoscope example in no time and still avoid tying yourself to C++ish LLVM. I'm not sure how big of a deal that stability thing is though, you still have to cover everything with tests, so who cares if it breaks a bit in future releases?
- exDM69 10y ago
  > The IR is highly unstable, especially the text representation, which is basically just a debugging tool. It's not guaranteed to be stable, but it's not "highly unstable" either. Not too many breaking changes have been introduced in the past few years and it's unlikely that you'd hit those parts when hand writing it. Not that I'd recommend hand writing LLVM IR. It's a shame that we don't have an actual portable IR, which would not be tied to toolchain version or contain target specifics. LLVM IR can't be used as such for a portable IR, which is why we've seen efforts like SPIR-V (Vulkan GPU IR) and WebAssembly (IR for browsers), both of which are very similar to LLVM IR (and a lot of work was duplicated).
  - fmap 10y ago
    WebAssembly is very different from LLVM IR, because it is essentially just the greatest common denominator of what existing JavaScript VMs handle in the backend. For instance, WebAssembly allows only reducible control flow, has very limited support for function pointers, and a particularly nasty memory model (linear memory, which precludes any kind of non-trivial alias analysis and optimization). All of these things may change in the future (apart from the reducible control flow restriction), but, at the moment, the goal of WebAssembly is just to have a viable compilation target for C++ in the browser. Google was championing LLVM IR for this purpose in the form of pnacl, but that was not enough of a compromise to work on the web platform. :(
the_duke 10y ago
The C api is probably the best bet. Most projects that aren't written in C++ thenselves use the C api. It has fewer features than the full C++ api, but is more stable.

hawkice 10y ago

Presumably because it allows a workflow that skips over parsing (and possibly error prone generating code). Also allows generators to e.g. lint things without a bananas workflow.

achamayou 10y ago

Because LLVM makes no guarantees about IR compatibility between releases. With the API at least, your compiler can catch the larger breaks when you upgrade, and they're likely to come with more doc/comments and change notes than the IR tweaks.

nhaehnle 10y ago
To be more precise, there is no guarantee at all about textual IR compatibility. Compatibility of bitcode, which is a binary representation of IR, is meant to be preserved across a very generous range of LLVM releases (but not forever).

legulere 10y ago

The IR is highly unstable, especially the text representation, which is basically just a debugging tool. The bitcode format is rather complicated, but at least there is backwards compatibility. LLVM is the library, so you are bound to it anyway. Further by having code for emiting IR you are basically just copying functionality that already exists.

zzzcpan 10y ago
You can make a perfectly stable IR from that Kaleidoscope example in no time and still avoid tying yourself to C++ish LLVM. I'm not sure how big of a deal that stability thing is though, you still have to cover everything with tests, so who cares if it breaks a bit in future releases?
exDM69 10y ago
> The IR is highly unstable, especially the text representation, which is basically just a debugging tool. It's not guaranteed to be stable, but it's not "highly unstable" either. Not too many breaking changes have been introduced in the past few years and it's unlikely that you'd hit those parts when hand writing it. Not that I'd recommend hand writing LLVM IR. It's a shame that we don't have an actual portable IR, which would not be tied to toolchain version or contain target specifics. LLVM IR can't be used as such for a portable IR, which is why we've seen efforts like SPIR-V (Vulkan GPU IR) and WebAssembly (IR for browsers), both of which are very similar to LLVM IR (and a lot of work was duplicated).
- fmap 10y ago
  WebAssembly is very different from LLVM IR, because it is essentially just the greatest common denominator of what existing JavaScript VMs handle in the backend. For instance, WebAssembly allows only reducible control flow, has very limited support for function pointers, and a particularly nasty memory model (linear memory, which precludes any kind of non-trivial alias analysis and optimization). All of these things may change in the future (apart from the reducible control flow restriction), but, at the moment, the goal of WebAssembly is just to have a viable compilation target for C++ in the browser. Google was championing LLVM IR for this purpose in the form of pnacl, but that was not enough of a compromise to work on the web platform. :(

the_duke 10y ago

The C api is probably the best bet. Most projects that aren't written in C++ thenselves use the C api. It has fewer features than the full C++ api, but is more stable.