<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jun 13, 2011, at 4:49 PM, Andrew Trick wrote:</div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>On Jun 13, 2011, at 4:33 PM, John McCall wrote:<br><br><blockquote type="cite">On Jun 13, 2011, at 3:43 PM, Andrew Trick wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Optimizing across an exceptional control edge is not awkward at all because dominance properties hold within an extended basic block. Most current LLVM transforms can be easily adapted to operate on an EBB. You mainly need a slightly smarter local instruction iterator. The same cannot be said about teaching passes, and the people who write them, to understand implicit control flow edges "within" blocks.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">...what on earth are you imagining is being proposed here? Basic blocks remain single-entry, and for the purposes of dominance they're single-exit in exactly the same way that LLVM's current basic blocks are single-exit: there are at most two exit points, whose location does not depend on the instructions in the "body" of the block. Dominance is not fundamentally changed. In particular, the most important property by far — transitivity of dominance through non-phis — still holds.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">And yes, working with invoke instructions is annoying, in part because of the possibility that the normal edge is critical, which is an invented problem forced on us by the terminator representation.<br></blockquote><br>I understand all of your arguments yet reach the opposite conclusion. In neither solution does the dominance property supposed to change. It's just hard to maintain correctly when trapping instructions don't terminate. Yes, handling critical CFG edges is annoying--so don't do it.<br><br>Whatever needs to be done to handle explicit "trapping" control flow already needs to be done to successfully optimize regular control flow. No change in representation needed.<br><br>-Andy</div></blockquote></div><br><div><div>One thing I have to admit. It's a bit annoying looking at a CFG with an exceptional edge every few instructions when there is no handler or cleanup code at all (just a bunch of pure "unwind" edges). That is the only disadvantage I can see.</div><div><br></div><div>I solved that in the past by simply telling the VCG viewer to hide exceptional edges. You could likewise strip them when generating DOT.</div><div><br></div><div>If cleanup-free "unwind" edges really dominate the CFG, it might be worthwhile, as an IR compression technique, to represent only those implicitly as a special case. No fundamentally new IR representation is required. The tradeoff would still be a more complex IR because the inliner would have to convert traps to explicit control flow, and IR analysis would have to be aware of control dependencies on the implicit traps. Given the extra complexity, it would be nice to know first if the unwind edges are going to be a real problem in practice.</div></div><div><br></div><div>-Andy</div></body></html>