Mir: introduce overflow operations

[nikomatsakis]

Currently the MIR doesn't handle overflow. My intended design was to add 'overflow operations' that yield a tuple (overflow-flag, result). This is roughly how LLVM does things. We would then check for overflow and panic if it occurs. @Aatch independently described this design as option 3.

[nikomatsakis]

See also @eddyb's comment: #27840 (comment)

[Aatch]

I've just looked into doing this, and have something mostly working right now. The main problem is that the codegen is much worse than the current system due to the branches and checking being more explicit now. This means that the (T, bool) has to be stored on-stack, then read from immediately.

An idea I had to try to improve this is to allow larger temporaries to have their allocas omitted as well. Part of this requires having a way to get at the fields without using an lvalue, which I have done using a new ExtractField value. This should allow it to work with immediate aggregates like those produced by the overflow intrinsics.

[nikomatsakis]

@Aatch Is this ExtractField something you are proposing adding to MIR?

[eddyb]

@Aatch You could generalize FatPtr to any pair of values, I think.

[Aatch]

@nikomatsakis yes. It actually looks to be working surprisingly well. It's effectively a short-hand for Rvalue::Use(Operand::Consume(Lvalue::Projection(<field projection>))). I also disabled the code that forces an alloca for non-scalar types and everything seems to still be working, though I haven't checked that much. As far as I can tell, the comment about having to have two paths for GEP vs extractvalue is actually misleading as GEP generally corresponds to a projection, which marks a temp as requiring a alloca and therefore uses a GEP.

The codegen for overflow checking by the MIR is now basically the same as the codegen done by the current trans path, which was what my goal was. I'll have a PR ready soon I hope, so you can see what is going on.

[Aatch]

I experimented with supporting "SSA lvalues", and it gets complicated quick. However, I think we'll want it to improve codegen around function calls, which still require an on-stack location for the return. I think I'll try to tackle that first, since it's going to be a bigger project.

[Aatch]

Ok, so making the codegen better turns out to be surprisingly complicated. So I'm going to punt that to some future person.

Instead I've focussed on getting the rest of the checks in. The checks for x/0, x % 0, MIN / -1 and MIN % -1 are generated verbatim in the MIR as is the check for -MIN.

[eddyb]

@Aatch I believe the cleanest solution would be to generalize FatPtr to any pair of immediates.
This also removes any boolean casting because a bool immediate is an i1.

[pnkfelix]

This is closed by PR #33905, right?

[eddyb]

Indeed. Must've missed it when I made the PR.