<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 15, 2016, 3:38 PM Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Daniel,<br>
<br>
Daniel Berlin wrote:<br>
 >     /* Add fake edges to the function exit for any non constant and non<br>
 >          noreturn calls (or noreturn calls with EH/abnormal edges),<br>
 >          volatile inline assembly in the bitmap of blocks specified by<br>
 >     BLOCKS<br>
 >          or to the whole CFG if BLOCKS is zero.<br>
 >     ...<br>
 ><br>
 >          The goal is to expose cases in which entering a basic block does<br>
 >          not imply that all subsequent instructions must be executed.  */<br>
 ><br>
 ><br>
 > Note that this is also necessary to makes post-dominance correct (but we<br>
 > already do it in most cases, but i think there are still bugs open about<br>
 > correctness)<br>
<br>
Yeah, right now in LLVM we cannot rely on post-dominance to conclude<br>
"guaranteed to execute" which isn't ideal.  There's at least one place<br>
I know where a more precise post-dominance could be used. :)<br>
<br>
 > For dominance, the dominance relationship for exit blocks a noreturn<br>
 > blocks reach also changes , though i don't honestly remember if it's<br>
 > material or not, and i'm a bit lazy to think about it.  But here's an<br>
 > example:<br>
 ><br>
 ><br>
 > IE given<br>
 ><br>
 > A (may-throw)<br>
 > |<br>
 > v<br>
 > B<br>
 > |<br>
 > v<br>
 > C (exit)<br>
 ><br>
 ><br>
 > Here, we have A dominates B dominates C<br>
 ><br>
 > So the dominator tree is<br>
 > A<br>
 > |<br>
 > v<br>
 > B<br>
 > |<br>
 > v<br>
 > C<br>
 ><br>
 > Now, if you add an edge from A to C, you have:<br>
 ><br>
 > A dominates B<br>
 > Neither B nor A dominate C (C's idom is somewhere above, so it's in a<br>
 > sibling tree somewhere).<br>
<br>
Not sure I understand this example -- won't C's new idom be A?  The new<br>
graph is this, right:<br>
<br>
A -> C<br>
A -> B<br>
B -> C<br>
<br>
?<br></blockquote></div><div><br></div><div>Yes I originally constructed the graph with two blocks with may throw calls, then simplified it and screwed up. Such is Friday 😀</div><div>I noticed right after I sent it and left for the day but not before you caught it. </div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
 ><br>
 ><br>
 > IE<br>
 ><br>
 > A    C<br>
 >   |<br>
 > B<br>
 ><br>
 ><br>
 > In GCC, there is a single exit block, and it is always empty (returns<br>
 > are connected to the exit block).<br>
 > Thus, the above will not prevent an optimization that should otherwise<br>
 > happen, from happening.<br>
 ><br>
 > Because LLVM's exit blocks contain real code, it may<br>
 ><br>
 > You can actually get even worse (ie really wrong) situations if the<br>
 > "exit" blocks somehow have successors, but thankfully we don't have a<br>
 > case where that happens that i know :)<br>
 ><br>
 ><br>
</blockquote></div>