On Jun 22, 2014, at 10:00 PM, Daniel Micay <danielmi...@gmail.com> wrote:
> On 23/06/14 12:49 AM, Cameron Zwarich wrote:
>> On Jun 22, 2014, at 9:35 PM, Daniel Micay <danielmi...@gmail.com
>> <mailto:danielmi...@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
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
