Inline LLVM IR


#1

Currently Rust supports inline assembly, which is great for micro-optimization for specific architectures. Thanks to #[cfg] you can write both a pure rust version of a function, and then for important architectures you can also write hand-optimized assembly versions. This enables people to write code bases that are both generally portable, and also highly optimized for specific platforms.

I’m thinking it could be useful to add another option into the mix: inline IR.

Inline IR would get passed through without optimization passes. This would allow a programmer to write a version of a function that sits somewhere between pure rust and hand-coded assembly in terms of portability and level of control. It would allow for finer control than pure rust, but unlike assembly still be somewhat portable. Of course, IR is not 100% architecture agnostic (e.g. little vs big endian, pointer type sizes, etc.), but it abstracts a lot of things away while still providing something reasonably close to per-instruction control.

So am I just crazy, or do other people also think this could be useful?


#2

More informations for those not knowing IR:

IR is better than assembly AOSA LLVM


#3

There was a proof-of-concept patch implementing this a while ago. I think personally think it would be very neat, and would allow e.g. implementing some intrinsics in the libraries rather than the compiler. However, there are some downsides:

  • it would chain rustc and the ecosystem to LLVM: if libraries start using it, alternative compilers are forced to handle LLVM IR or are unusable/slow with those libraries
  • the IR format is not stable: a library may compile with LLVM 3.4 and 3.5, but not with 3.3 or 3.6.

#4

@huon

it would chain rustc and the ecosystem to LLVM

I don’t think it has to. x86 assembly is specific to x86 architectures. Similarly, IR would be be specific to LLVM-based compilers. You would use a #[cfg] to make it conditional on IR support, just like you would use #[cfg] to make x86 assembly conditional on x86 architecture.

the IR format is not stable: a library may compile with LLVM 3.4 and 3.5, but not with 3.3 or 3.6.

I did not realize this. This makes me much, much more wary of the idea. Indeed, I think it’s perhaps best not to support inline IR then.

I do wonder if there’s something else out there that’s similar in nature, but stable.


#5

Shouldn’t it be possible to link to LLVM IR? Granted, that would mean chaining the IR to a respective LLVM version, but it might still be useful in some circumstances.