<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Jun 22, 2014, at 9:35 PM, Daniel Micay <<a href="mailto:danielmicay@gmail.com">danielmicay@gmail.com</a>> wrote:<br><div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">An operation that can unwind isn't pure. It impedes code motion such as<br>hoisting operations out of a loop, which is very important for easing<br>the performance issues caused by indexing bounds checks. LLVM doesn't<br>model the `nounwind` effect on functions simply for fun.<br></div></blockquote></div><br><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cameron</div></body></html>