[rust-dev] Integer overflow, round -2147483648

comex comexk at gmail.com
Sun Jun 22 21:46:05 PDT 2014

On Mon, Jun 23, 2014 at 12:35 AM, Daniel Micay <danielmicay at gmail.com> wrote:
> An operation that can unwind isn't pure. It impedes code motion such as
> hoisting operations out of a loop, which is very important for easing
> the performance issues caused by indexing bounds checks. LLVM doesn't
> model the `nounwind` effect on functions simply for fun.

No it doesn't!  Or maybe it does today, but an unwindable operation is
guaranteed to be repeatable without consequence, which I'd like to
think can account for most cases where operations are hoisted out of
loops (again, could be wrong :), and not to modify any memory (unless
it traps, but in Rust at that point you are guaranteed to be exiting
the function immediately).

In particular, the only reason I can see why an impure operation would
require repeating a bounds check is if the compiler thinks it could
modify the size of the array, or the index, or something else in
memory.  But it cannot.

Yeah, yeah, Rust is designed for 2014 not 2024, and I admit "LLVM
cannot do this right now" is a perfectly good reason in this context.
But I want to differentiate the different arguments being made here.

> Unwinding is a stateful effect, and any code that would be otherwise
> pure is no longer pure if it has the potential to unwind. It's not
> simply a matter of unwinding or not unwinding, the compiler needs to
> ensure that the source of the unwinding is the same.

Only if it crosses initialization of objects with destructors.  It
doesn't matter if the stack trace is off.

> I provided an example demonstrating the cost with `clang`.

First of all, that's including actual bounds checks as opposed to
merely assuming impurity/unwinding, no?  Again, simply to
differentiate the arguments...

Second of all, it may be possible to do the checks more efficiently.
I should look at clang's assembly output.

More information about the Rust-dev mailing list