4 ms·

Do you know if you can compile to a text form of the LLVM IR? Also wondering how you'd interface with a GC if you did that.

heinrich5991 11y ago
I believe LLVM IR, even in its textual form, is not considered a stable interface.
- pcwalton 11y ago
  It's not, but keeping up with upgrades generally isn't a problem. Not enough to outweigh the downsides of compiling to C.
  - tachyonbeam 11y ago
    And to be fair, it's not like the LLVM C API is going to remain the same forever, that changes too.
    - erickt 11y ago
      Last I worked on llvm-c, it was supposed to stay backwards compatible. They do add new functionality but the old API should still work until llvm 4. For rust, while we have been broken by bad code we generated and llvm bugs, I can't recall if the API ever was changed out from under us.
pcwalton 11y ago
Yeah, you can compile to LLVM IR in assembly format and then run the result through llc. But you will pay in compilation time for this due to the serialization and deserialization steps, so I can't see a situation in which it'd be worth it to do so. The LLVM GC interface is controlled through intrinsics, so you can access it through the human-readable IR representation just as you can with the API.
- andrewchambers 11y ago
  > so I can't see a situation in which it'd be worth it to do so. The obvious one is not having a giant build time dependency that might change and be at different versions on different platforms. The text interface is far more stable. The problem I had with doing this is how picky llvm is when it comes to ordering your temporary registers.
  - deleted 11y ago
    [deleted]
  - Gankro 11y ago
    As far as I've seen, the text interface is radically more unstable. Like when they recently striped types from pointers, I was like "oh no that sounds like it'll be a lot of work to upgrade to", and all the backend peeps seemed to think it wasn't a big deal because LLVM's API handled it. Particularly when you factor in that any breakage in the direct LLVM API can often be resolved by looking at what Clang did when it upgraded.
    - andrewchambers 11y ago
      That is a shame then.
BruceM 11y ago
In Open Dylan (http://opendylan.org/ http://opendylan.org/), we have a library of our own written in Dylan that lets us write out LLVM IR in binary files. We have to update it as LLVM changes, but that typically isn't all that bad. We have some macros and a bunch of functions then that make emitting LLVM IR simpler. For example, the "ins--iterate" and "ins--if" / "ins--else" macros in this code handle phi nodes and so on: https://github.com/dylan-lang/opendylan/blob/05271f6fec9da05ef64c7cbba6c9c0fd271d88d7/sources/dfmc/llvm-back-end/llvm-entry-points.dylan#L522 https://github.com/dylan-lang/opendylan/blob/05271f6fec9da05... This library is currently in the process of being updated from LLVM 3.5 to current HEAD as debug info has changed significantly upstream. After that, we will be landing some documentation for it as well. If you're interested in learning or hearing more about this, we're typically around on #dylan on freenode IRC.

heinrich5991 11y ago

I believe LLVM IR, even in its textual form, is not considered a stable interface.

pcwalton 11y ago
It's not, but keeping up with upgrades generally isn't a problem. Not enough to outweigh the downsides of compiling to C.
- tachyonbeam 11y ago
  And to be fair, it's not like the LLVM C API is going to remain the same forever, that changes too.
  - erickt 11y ago
    Last I worked on llvm-c, it was supposed to stay backwards compatible. They do add new functionality but the old API should still work until llvm 4. For rust, while we have been broken by bad code we generated and llvm bugs, I can't recall if the API ever was changed out from under us.

pcwalton 11y ago

Yeah, you can compile to LLVM IR in assembly format and then run the result through llc. But you will pay in compilation time for this due to the serialization and deserialization steps, so I can't see a situation in which it'd be worth it to do so. The LLVM GC interface is controlled through intrinsics, so you can access it through the human-readable IR representation just as you can with the API.

andrewchambers 11y ago
> so I can't see a situation in which it'd be worth it to do so. The obvious one is not having a giant build time dependency that might change and be at different versions on different platforms. The text interface is far more stable. The problem I had with doing this is how picky llvm is when it comes to ordering your temporary registers.
- deleted 11y ago
  [deleted]
- Gankro 11y ago
  As far as I've seen, the text interface is radically more unstable. Like when they recently striped types from pointers, I was like "oh no that sounds like it'll be a lot of work to upgrade to", and all the backend peeps seemed to think it wasn't a big deal because LLVM's API handled it. Particularly when you factor in that any breakage in the direct LLVM API can often be resolved by looking at what Clang did when it upgraded.
  - andrewchambers 11y ago
    That is a shame then.

BruceM 11y ago

In Open Dylan (http://opendylan.org/ http://opendylan.org/), we have a library of our own written in Dylan that lets us write out LLVM IR in binary files. We have to update it as LLVM changes, but that typically isn't all that bad. We have some macros and a bunch of functions then that make emitting LLVM IR simpler. For example, the "ins--iterate" and "ins--if" / "ins--else" macros in this code handle phi nodes and so on: https://github.com/dylan-lang/opendylan/blob/05271f6fec9da05ef64c7cbba6c9c0fd271d88d7/sources/dfmc/llvm-back-end/llvm-entry-points.dylan#L522 https://github.com/dylan-lang/opendylan/blob/05271f6fec9da05... This library is currently in the process of being updated from LLVM 3.5 to current HEAD as debug info has changed significantly upstream. After that, we will be landing some documentation for it as well. If you're interested in learning or hearing more about this, we're typically around on #dylan on freenode IRC.