[rust-dev] Integer overflow, round -2147483648
danielmicay at gmail.com
Sun Jun 22 22:00:57 PDT 2014
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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Rust-dev