<br><br><div class="gmail_quote">On Tue, Dec 6, 2011 at 5:29 PM, Dan Gohman <span dir="ltr"><<a href="mailto:gohman@apple.com">gohman@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
On Dec 6, 2011, at 10:07 AM, Paul Robinson wrote:<br>
<br>
> On Tue, Dec 6, 2011 at 9:06 AM, David A. Greene <<a href="mailto:greened@obbligato.org">greened@obbligato.org</a>> wrote:<br>
> Dan Gohman <<a href="mailto:gohman@apple.com">gohman@apple.com</a>> writes:<br>
><br>
> > For example, suppose we want to convert the && to &, and the ?: to a<br>
> > select, in this code:<br>
> ><br>
> > if (a && (b ? (c + d) : e)) {<br>
> ><br>
> > because we have a CPU architecture with poor branch prediction, or<br>
> > because we want more ILP, or because of some other reason. Here's what the<br>
> > LLVM IR for that might look like:<br>
> ><br>
> >    %t0 = add nsw i32 %c, %d<br>
> >    %t1 = select i1 %b, i32 %t0, i32 %e<br>
> >    %t2 = icmp ne i32 %t1, 0<br>
> >    %t3 = and i1 %a, %t2<br>
> >    br i1 %t3, ...<br>
> ><br>
> > The extra branching is gone, yay. But now we've put an add nsw out there<br>
> > to be executed unconditionally. If we make the select an observation<br>
> > point, we'd have introduced undefined behavior on a path that didn't<br>
> > previously have it.<br>
><br>
> Unless the undefined behavior only triggered if the select actually<br>
> produced a poisoned result.  Then it should have the same behavior as<br>
> the branch, no?<br>
<br>
> > A foodtaster instruction doesn't really solve this problem, because<br>
> > we'd have to put it between the add and the select, and it would be<br>
> > just as problematic.<br>
><br>
> Or you put it immediately after the select.<br>
><br>
> That was my thinking. The select is an observation point for its first operand,<br>
> but then merely propagates poison from the second or third, just like any<br>
> computational instruction would.<br>
> The icmp is an observation point for both inputs.<br>
<br>
</div></div>Put the observation point on the add, the select, the icmp, or even the<br>
and, or between any of them, and it'll still be before the branch. That<br>
means that the code will have unconditional undefined behavior when the<br>
add overflows, which the original code did not have.<br>
<font color="#888888"><br>
Dan<br>
<br>
</font></blockquote></div>Sorry, you lost me there.  The behavior of the observation point isn't undefined<div>unless you took the overflow path in the first place. I don't see how that makes</div><div>it unconditionally undefined.</div>
<div><br></div><div>The discussion started based on a premise of propagating poison values past</div><div>all these kinds of places; now you don't want to let me move them past any</div><div>of these places? Clearly I don't follow how you think my suggestion diverges</div>
<div>unacceptably from your original sketch. Which might mean it's time to bail...</div><div><br></div><div><div>Pogo</div></div>