On 23/06/14 12:17 AM, comex wrote: > On Sun, Jun 22, 2014 at 5:05 PM, Daniel Micay <danielmi...@gmail.com> wrote: >> Anyway, no one has offered an explanation of how they're >> planning on integrating this into LLVM and how they propose turning a >> trapping operation into unwinding across various platforms. > > Isn't that what asynchronous unwind tables are for? The actual > platform glue isn't that difficult on the platforms I know of - at the > cost of making interoperability with C programs that use signal > handlers tend to break, but that's not fatal.
Asynchronous unwind tables are the low-level implementation detail for providing this support. However, that doesn't mean it has well-defined behaviour in LLVM IR. LLVM has modelling of effects like unwinding, and it does assume that unwinding cannot simply occur anywhere. If it had to make that assumption, it would be far less capable of performing optimizations. In the case of MPX, you could add new LLVM intrinsics and provide a hard guarantee that whatever signal handler glue you use to turn MPX into unwinding *never* occurs outside of those LLVM intrinsics. > On Reddit you mentioned that unwinding impedes optimization. But I'd > still like to hear more specifics... what sort of optimizations? I > believe you if you say that simply allowing unwinding (without > considering the cost of actually trapping*) significantly impedes > performance today, but can some of that can be fixed? In terms of > true limitations, I can think of: 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 more speculative execution - 'foo ? x + 2 : y + 4' now must be a > branch instead of a cmov. But how common is this in practice? 'foo ? > x + 2 : x + 4' can of course be done with a cmov. Bigger statements > turn into branches anyway in practice. > > - Can't reorder arithmetic with respect to stores that could be > visible to destructors. Does it matter? It's still fine to eliminate > common subexpressions as long as they're only computed when one of > their instances should be. > > My intuition could be wildly off, but I don't see why this should be > such a big deal. And the value many people seem to assign to the > issue (albeit which I'm not presupposing is merited) suggests that > making any useful improvements to LLVM in this case should be doable. > (Easy to say without volunteering to do it myself, I know...) 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. An abort (`llvm.trap`) or undefined behaviour is similar in that it adds an effect and prevents the compiler from doing as much with the code. However, the unwinding invariants are harder to maintain and LLVM doesn't even take on this problem. > Even if this turns out to be a bad idea in the end, I'm not sure this > thread has enough of a real, measured idea of the costs involved yet, > and again, people seem to think it's important enough that I don't > think it's worth giving up without that. Yes, even though 1.0 is > soon. Just my two cents. I provided an example demonstrating the cost with `clang`.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
