<div class="gmail_quote">On Tue, Dec 6, 2011 at 9:06 AM, David A. Greene <span dir="ltr"><<a href="mailto:greened@obbligato.org">greened@obbligato.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">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>
</div>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>
<div class="im"><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>
</div>Or you put it immediately after the select.<br></blockquote><div><br></div><div>That was my thinking. The select is an observation point for its first operand,</div><div>but then merely propagates poison from the second or third, just like any</div>
<div>computational instruction would.</div><div>The icmp is an observation point for both inputs.</div><div><br></div><div>Pogo</div></div>