<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Feb 8, 2015 at 1:19 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Reid Kleckner" <<a href="mailto:rnk@google.com">rnk@google.com</a>><br>
> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
> Cc: "David Majnemer" <<a href="mailto:david.majnemer@gmail.com">david.majnemer@gmail.com</a>>, "Nuno Lopes" <<a href="mailto:nuno.lopes@ist.utl.pt">nuno.lopes@ist.utl.pt</a>>, "John Regehr"<br>
> <<a href="mailto:regehr@cs.utah.edu">regehr@cs.utah.edu</a>>, "LLVM Developers Mailing List" <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
</span><span class="">> Sent: Sunday, February 8, 2015 2:20:49 PM<br>
> Subject: Re: [LLVMdev] RFC: Proposal to Remove Poison<br>
><br>
><br>
</span><div><div class="h5">> On Sun, Feb 8, 2015 at 10:02 AM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> wrote:<br>
><br>
> When you say, "we'd like to", I'm assuming your justification for<br>
> this is so that we can model poison using these undef semantics. Is<br>
> that correct?<br>
><br>
> Yes, but I also think 'icmp sgt i32 undef, %a -> i1 undef' is a<br>
> pretty reasonable transform by itself. Well-defined programs should<br>
> never observe the result of the compare.<br>
<br>
</div></div>I'm somewhat concerned that this is unsound. For example, imagine I have the following:<br>
<br>
void foo(int &a, int n) {<br>
int c = INT_MAX, r = 0;<br>
for (int i = 0; i < n; ++i, --c) {<br>
if (a > c)<br>
r += a;<br>
else<br>
a = bar();<br>
}<br>
<br>
return r;<br>
}<br>
<br>
called like this:<br>
<br>
int q;<br>
return foo(&q, 5);<br>
<br>
However, we now have a situation where:<br>
1) in the first iteration the value loaded from &a is uninitialized<br>
2) after inlining the loop will likely be fully unrolled, and so the initial value loaded will be replaced by an undef<br>
3) it is the fact that, in that first iteration, (a > c, where c == INT_MAX) is always false that protects the undefined value from propagating further<br>
<br>
I'm also assuming that it is desirable that 'int c = INT_MAX' should have the same behavior as 'int c = opaque_func_that_returns_INT_MAX()'.<br>
<br>
To be clear, I'm not entirely convinced that this is a well-defined C++ program (*), however, I believe it is well defined under our current semantics at the IR level. What is being proposed would change that.<br></blockquote><div><br></div><div>I don't think that program is reasonable. I also don't think my proposal changes the facts on the ground.</div><div><br></div><div>consider:</div><div><div>bool f(int x, int y, bool c) {</div><div> int add;</div><div> if (c)</div><div> add = x + y;</div><div> return add > x;</div><div>}</div></div><div><br></div><div>Are we permitted to optimize this program to:</div><div>bool f(int x, int y, bool c) {</div><div> return y > 0;</div><div>}</div><div><br></div><div>?</div><div><br></div><div>We do so today.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
(*) 8.5p12 says only, "If an indeterminate value is produced by an evaluation, the behavior is undefined except in the following cases..." [there are some special cases involving values of character type]. There is also a footnote on 3.9.1p6, discussing bool, that says, "Using a bool value in ways described by this International Standard as `undefined,` such as by examining the value of an uninitialized automatic object, might cause it to behave as if it is neither true nor false." But it is not really clear to me whether (c > INT_MAX) is an evaluation having an indeterminate value (except via some circular reasoning).<br>
<div class=""><div class="h5"><br>
-Hal<br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div></div>