[rust-dev] Integer overflow, round -2147483648

Cameron Zwarich zwarich at mozilla.com
Sun Jun 22 22:16:51 PDT 2014


On Jun 22, 2014, at 10:00 PM, Daniel Micay <danielmicay at gmail.com> wrote:

> On 23/06/14 12:49 AM, Cameron Zwarich wrote:
>> On Jun 22, 2014, at 9:35 PM, Daniel Micay <danielmicay at gmail.com
>> <mailto: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.
>> 
>> It gets easier to optimize if you adopt a less precise model of
>> exceptions. For example, you could pick a model where you preserve
>> control dependence and externally visible side effects, but allow
>> reordering in other cases. This does get tricky if destructors
>> themselves have externally visible side effects that are dependent on
>> intervening stores that can be elided.
>> 
>> This probably requires whole-program compilation with some knowledge of
>> externally visible side effects, or more restrictions placed on
>> destructors than there are currently. It also is hard to make work with
>> unsafe code, since unsafe code might require exact placement of
>> unwinding for memory safety in destructors.
>> 
>> Cameron
> 
> Adding restrictions to destructors sounds like adding an effects system
> to Rust. I think the trait system will get in the way of an attempt to
> do that. For example, should a trait like `Eq` use pure methods? If
> they're not pure, then no implementation can be considered pure in
> generic code. Anything using that generic code can't be considered pure,
> and so on.

We already have a need for limiting what destructors can do:

https://github.com/rust-lang/rust/issues/14875

In the case of optimizations, at least you always have the conservative option of preserving the exact ordering of unwinding if you can’t prove that it doesn’t matter.

Cameron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140622/5238c477/attachment.html>


More information about the Rust-dev mailing list