<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 3, 2014 at 1:27 PM, Vadim Chugunov <span dir="ltr"><<a href="mailto:vadimcn@gmail.com" target="_blank">vadimcn@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>If we added unwind target to every potentially throwing instruction (loads, stores, all binary operations), wouldn't all such instructions have to become BB terminators?   I'd expect that CFG would then end up consisting mostly of single-instruction BBs. This can't be good for compilation performance and optimizations...<br></div></div></div></blockquote><div><br></div><div>Yes. This merely exposes the high cost of what the user is requesting. We could invent a more compact representation for a run of single-instruction bbs that share unwind edges, but *reliable* async exception support is fundamentally bad for optimization. Analysis passes need to see all the implicit edges.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div></div>Another vague idea: what if lifetime.start() returned some kind of a token, which lifetime.end() has to consume?   That would prevent transformations that don't preserve lifetime scopes (such as the one you've described), wouldn't it?</div></div></blockquote><div><br></div><div>No, the transform is still valid. The block with the switch would contain a massive list of phis between undef and the incoming SSA values that were previously used by successor basic blocks. The incoming undef edge is not actually dynamically reachable, so it's safe to add undef there.</div></div></div></div>