<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>LLVM's design decision is one where everything has to explicitly care about implicit early exits to get correct answers (and not to harp too much, but "not everything does", years later).  If they don't, they will get wrong answers.</div><div><br></div></div></div></div></blockquote><div><br></div><div>So, ironically, while looking at this, i noticed it turns out LLVM's PRE in GVN is another place that does not do this correctly either.</div><div><br></div><div>It will insert and hoist loads past may-throw calls depending on whether it thinks the call aliases the pointer or not (IE depending on what memdep tells it, and memdep only cares about aliasing here when coming up with deps), regardless of whether the call is nounwind or not.  This is rare but can happen.</div><div><br></div><div>This is because memdep does this:<br>       // If the call has no effect on the queried pointer, just ignore it.<br></div><div>So it does not give a dep, and PRE then never does anything else to check whether there is a may-throw call in the way of the hoist.</div><div><br></div><div>Testcase and patch coming.</div><div><br></div><div>Even more ironically, in gcc land, the non-local case would have been prevented by this code GVN tries to use:</div><div><br></div><div><div><div>     // If any of these blocks has more than one successor (i.e. if the edge we</div><div>     // just traversed was critical), then there are other paths through this</div><div>     // block along which the load may not be anticipated.  Hoisting the load</div><div>     // above this block would be adding the load to execution paths along</div><div>     // which it was not previously executed.</div><div>     if (TmpBB->getTerminator()->getNumSuccessors() != 1)</div><div>       return false;</div></div></div><div><br></div><div>Since it would have had edges to the exit block in any predecessor with a may-throw call, it would have gotten the right answer.</div><div><br></div><div>Anyway, since i still don't plan on proposing changes here, i'm going to stop harping on this for a while.</div><div><br></div></div></div></div>