<div dir="ltr"><div>Ah, understood. Thank you for the explanation.<br><br></div>Patch checked in here:<br><a href="http://reviews.llvm.org/rL230564">http://reviews.llvm.org/rL230564</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 23, 2015 at 10:22 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Feb 16, 2015 at 2:07 PM, Sanjay Patel <span dir="ltr"><<a href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>></span> wrote:<br><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><div>Hi Eli, <br><br>The change you are suggesting would prevent equality propagation of a non-constant FP value. Is that the intention? If yes, why wouldn't we want to do that optimization? We do that for the integer case.<br></div></div></div></blockquote><div><br></div></span><div>The constraint you're trying to express is "the optimization is not safe unless one of the operands is provably non-zero". There are multiple ways to express that; my suggestion is one of them.  The current code does not express that.  If you take the fcmp_oeq_zero testcase and replace 0.0 with some argument %z, and %z happens to be 0.0, you run into exactly the same problem.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>-Eli<br></div></font></span></div></div></div>
</blockquote></div><br></div>