[rust-dev] Integer overflow, round -2147483648

comex comexk at gmail.com
Sun Jun 22 21:17:18 PDT 2014

On Sun, Jun 22, 2014 at 5:05 PM, Daniel Micay <danielmicay at 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...

More information about the Rust-dev mailing list