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. 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: - 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...) 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. * for now, anyway, since I'm responding to a post about how this isn't feasible for future architectures... _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
