[MIR] Implement overflow checking

[Aatch]

Implements overflow checking in the MIR. Also adds checking for x/0, x%0, MIN/-1 and MIN%-1.

Fixes#29769

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[Aatch]

This currently breaks documentation generation for libc, as it makes the panic lang item required during MIR construction.

/cc @alexcrichton

[oli-obk]

You can generate the correct ConstIsize variant directly, without casting to i64 and going through ConstIsize::new.

let val = match int_ty {
ast::IntTy::I32 => ConstIsize::Is32(std::i32::MIN),
ast::IntTy::I64 => ConstIsize::Is64(std::i64::MIN),
_ => bug!(),}

[alexcrichton]

This currently breaks documentation generation for libc, as it makes the panic lang item required during MIR construction.

Ah that's fine, I can fix that at some point upstream for libc

[nagisa]

What is the purpose of this hack? Does it always result in correct code in case of bugs (when somebody forgets to set a terminator)? If not, then lack of the terminator should just stay a bug, as it currently is.

[nagisa]

Have you considered a

BinaryOp(BinOp, Operand, Operand, bool) -trans-to-> (ValueRef, ValueRef)
^^^^ ^^^^^^^^ ^^^^^^^^ The overflow flag (plain undef in case bool = false)
| └ The result value
Whether the operation should use overflow checks

? Well, I guess there isn’t much difference, the current approach also looks fine.

[nagisa]

Doesn’t this branch ignore the check_overflow? Are we checking for division unconditionally in current trans?

[nagisa]

To me it seems like it would be cleaner to have something like

if !self.is_overflow_checked() || !op.is_checkable() || !ty.is_integral() { return block.and(Rvalue::BinaryOp(...) }

at the top, and then only do the branching based on the operator elsewhere in this function.

[DemiMarie]

Does this generate the LLVM intrinsics or explicit checks?

The LLVM documentation for frontends warns against using the intrinsics unless necessary.

[nagisa]

@drbo it does indeed emit intrinsics.

I do not see how one would check for overflow after the fact without intrinsics, and I’m doubtful implementing overflow detection for, say multiplication would be easy without intrinsics or inline assembly. Any ideas?

[Aatch]

@drbo that's almost certainly referring to the fact that you shouldn't use the intrinsics unless you actually need to check the result, which is the case here. If we don't check the result, we don't use the intrinsics, it's not like we emit the intrinsics for all arithmetic, just checked arithmetic.

Also, the impact on optimisation isn't a strong factor here, since most of the time chceked arithmetic is used because optimisations haven't been enabled.

[nikomatsakis]

I imagine we might want some more structured form of terminators here for these special checks (but that needn't derail this PR).

[nikomatsakis]

@Aatch ok I reviewed the PR. The code all makes sense and basically looks good to me. I have one question though, I thought you had mentioned some kind of change to MIR to make something analogous to LLVM's "extract-value"? I didn't see anything like that?

Otherwise, it seems like we have to settle the question of what to do about inlined code. I keep going back and forth.

Finally, I suspect we are going to want mildly higher-level terminators that are clearly "automatically inserted" so that things like constant propagation and so forth can recognize them, but I'm not sure about that.

[nikomatsakis]

Ah, just saw this comment saying that the codegen part was deferred.

[alexcrichton]

The libs team discussed the ramifications of this on the standard library today, and the conclusion was generally positive. We felt that if the standard library wants overflow checks it should write those overflow checks (e.g. with Duration).

@eddyb, could you clarify where this is relied on for pow? That's likely something that we should fix at thie source.

We did have some hesitation, however, at the consideration of this for the Add trait and relevant implementations. @aturon articulated the thought along the lines of if you're writing code that's adding numbers, that code should have overflow checks depending on how the crate is compiled.

I personally interpret that as expecting code like this to panic:

fnadd<T:Add>(a:T,b:T) -> T{
a + b
}fnmain(){add(200_u8,200_u8);}

I think with this PR, however, it will not panic? That'll get dispatched to the Add implementation in the standard library whose MIR does not have overflow checks?

[eddyb]

@alexcrichtonpow is specifically written so it behaves like any of the Add or Mul impls for primitives types, i.e. it can trigger an overflow panic if you're using it from debug mode.

[arielb1]

Also, the impact on optimisation isn't a strong factor here, since most of the time chceked arithmetic is used because optimisations haven't been enabled.

Debugopt builds are a thing, you know. I would not expect anyone to run their big testsuite on a non-opt build.

@alexcrichton

The Add impl of primitive types is "short-cutted" during type-checking, so it will work for arithmetic operations. However, other such methods, such as pow aren't.

We may want a #[rustc_inherit_overflow].

[alexcrichton]

@eddyb thanks! We should fix that to either always have overflow checks or always have none.

@arielb1

So would the example code snippet I pasted have overflow checks if compiled against an optimized standard library but the code itself was compiled in debug mode?

[eddyb]

@alexcrichton Well, the comments indicate that the behavior of pow is quite intentional, so at least some people are bound to see such a "fix" as a "regression".

@arielb1 The "short-cutting" only works when the types are known, though. If trait selection picks the impls in libcore, their method bodies will be used, not the built-in operations.