[MIR] Consider lowering some intrinsic functions to MIR

[Aatch]

Some intrinsic functions can be effectively implemented in pure MIR code. Notably, the wrapping and checked arithmetic functions, which can turn into regular BinaryOp and CheckedBinaryOp (when implemented) rvalues. Similarly intrinsics like move_val_init can be exactly represented in the MIR.

While relatively low impact right now, due to most intrinsics being used via wrapper functions, if/when we get MIR-level inlining, this would allow those intrinsics to better participate in optimisations.

[luqmana]

I had a branch that did exactly this a while back for transmute and a few others.

https://github.com/luqmana/rust/commits/mir-intrinsics

[Aatch]

@luqmana I have a branch that I was experimenting with that did the lowering while building, which I think makes more sense in some situations, though an intrinsic lowering pass in other cases may also be useful.

[aochagavia]

I would like to work on this, but don't know where to begin. Would it make sense to rebase @luqmana's branch first?

[nagisa]

Rebasing probably makes little sense. It’s a very old branch approaching the problem from a direction that would likely not work anymore, due to how much MIR has changed over time. IMO it would be easier to begin from scratch.

[aochagavia]

Thanks! I took a quick look at core::intrinsics and rustc_trans::intrinsic to get a bit of background information. Just to ensure I got the basics right, let me know if the following statements are correct:

1. intrinsics are just functions that are generated directly by the compiler (instead of being compiled Rust code, like most of the standard library). For instance, there is no way mem::size_of could be implemented as a normal function, so it is generated by the compiler.
2. Currently, intrinsics are generated by trans, which has a couple of downsides (they don't benefit from MIR optimizations, they cause code repetition if new backends are added, etc).
3. Lots of intrinsics seem backend-specific. For instance, float arithmetic intrinsics correspond to LLVM instructions.
4. Some intrinsics are not tied to a particular backend and can therefore be moved to MIR (mem::transmute seems like a good example, as it shouldn't generate any code at all. EDIT: I see it doesn't even exist in rustc_trans::intrinsic).

I have more questions, but I think I better make sure we are on the same line before I go on 😉

[nagisa]

they don't benefit from MIR optimizations

Rather than not benefiting, they inhibit them.

Everything else sounds about right.

[aochagavia]

Right, so now on with more questions. When you say that @luqmana's direction won't work anymore, do you mean that it would be a bad idea to write a MIR transformation that lowers intrinsics? I cannot imagine a different way of implementing this.

[nagisa]

MIR transformation will still work for most of the interesting intrinsics I think; although there may be a saner approach. What I mean is that the transformation in question was written a year ago, and MIR has changed so significantly since, that rebasing it properly would be equivalent (or even harder) than redoing it from scratch.

Also: when implementing this keep in mind the eventual move to EBBs.

[aochagavia]

Loosely based on @luqmana's code I wrote the following: https://github.com/aochagavia/rust/commit/0f9a70b3567b76b8d06ac3fd5f38426512d26128

There are a couple of FIXMEs, though. I left comments on some lines. @nagisa could you take a look at them and point me in the right direction? That would be great!

[steveklabnik]

Triage: is this bug still useful?