On Mon, Jun 23, 2014 at 12:35 AM, Daniel Micay <[email protected]> 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. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
