Hacker News Reader

Comment by tachyonbeam | Hacker News Reader

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.

View on HN

In Open Dylan (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/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.

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.

> 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.

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.

That is a shame then.

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

It's not, but keeping up with upgrades generally isn't a problem. Not enough to outweigh the downsides of compiling to C.

And to be fair, it's not like the LLVM C API is going to remain the same forever, that changes too.

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.

Reply on news.ycombinator.com