3 ms·
This is an interesting example. The store to x is dead and ought to be totally elided, but Rust will still emit an "overflow check" for an array that does not e
by millstone 10y ago
This is an interesting example. The store to x is dead and ought to be totally elided, but Rust will still emit an "overflow check" for an array that does not exist. This overflow check dominates the cost of the function.
If the optimizer determines a store is dead and can elide it, should it also elide the overflow checks? If "no," then it seems we've unnecessarily hamstrung the optimizer. If "yes," then whether a program panics is optimization-level dependent.
- petertodd 10y agoedit: re-reading your comment I suspect we're in violent agreement. :) > The store to x is dead and ought to be totally elided Yet, it's a clear sign of a bug in the program; the fact it happened to be elided in that case doesn't change the fact that it's almost certainly a bug that I want to know about. Heck, earlier today I wrote a Rust function along these lines: fn foo<A, B>(a: &A) -> &B { assert_eq!(size_of::<A>() == size_of::<B>()); unsafe { // do horrible low-level things } } The assertion is there to make sure that two generic type parameters that should have an identical size actually do. If they do in optimized builds the compiler knows the assertion is true and completely elides the assertion itself. If the sizes aren't identical, the assertion isn't elided and I'll quickly find the bug when the program crashes(1). I definitely wouldn't want that assertion to get elided just because the "horrible low-level things" happened to be categorized as undefined behavior! 1) Of course, a sufficiently smart compiler could detect that the assertion was false at compile time in this simplified example.