<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 22, 2016 at 1:37 PM, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/22/2016 01:14 PM, Jason Ekstrand wrote:<br>
> On Thu, Dec 22, 2016 at 1:13 PM, Ian Romanick <<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a>>> wrote:<br>
><br>
>     On 12/19/2016 09:32 PM, Jason Ekstrand wrote:<br>
>     > This sequence shows up The Talos Principal, at least under Vulkan,<br>
>     > and prevents loop analysis from properly computing trip counts in a<br>
>     > few loops.<br>
>     > ---<br>
>     >  src/compiler/nir/nir_opt_<wbr>algebraic.py | 8 ++++++++<br>
>     >  1 file changed, 8 insertions(+)<br>
>     ><br>
>     > diff --git a/src/compiler/nir/nir_opt_<wbr>algebraic.py b/src/compiler/nir/nir_opt_<wbr>algebraic.py<br>
>     > index 698ac67..cc70ad5 100644<br>
>     > --- a/src/compiler/nir/nir_opt_<wbr>algebraic.py<br>
>     > +++ b/src/compiler/nir/nir_opt_<wbr>algebraic.py<br>
>     > @@ -464,6 +464,14 @@ def bitfield_reverse(u):<br>
>     ><br>
>     >  optimizations += [(bitfield_reverse('x@32'), ('bitfield_reverse', 'x'))]<br>
>     ><br>
>     > +# For any comparison operation, "cmp", if you have "a != a && a cmp b" then<br>
>     > +# the "a != a" is redundant because it's equivalent to "a is not NaN" and, if<br>
>     > +# a is a NaN then the second comparison will fail anyway.<br>
>     > +for op in ['flt', 'fge', 'feq', 'fne']:<br>
>     > +   optimizations += [<br>
>     > +      (('iand', ('feq', a, a), (op, a, b)), (op, a, b)),<br>
>     > +      (('iand', ('feq', a, a), (op, b, a)), (op, b, a)),<br>
>     > +   ]<br>
><br>
>     I don't think this is right.  That will change (NaN == NaN) && (NaN !=<br>
>     7) from false to true.  Right?  You should just drop fne from the<br>
>     list... I think.  Math is hard.<br>
><br>
> Don't all comparisons with NaN return false?  Wouldn't NaN != 7 be<br>
> false?  Maybe I don't understand NaN!<br>
<br>
</div></div>As far as I'm aware, (!(a == b)) is always the same as (a !== b).<br>
According to<br>
<a href="https://en.wikipedia.org/wiki/IEEE_754-1985#Recommended_functions_and_predicates" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/<wbr>IEEE_754-1985#Recommended_<wbr>functions_and_predicates</a>,<br>
 a != a is how you can implement isnan().<br><div class="HOEnZb"><div class="h5"></div></div></blockquote><div><br></div><div>Bah!  I just wrote a small C program to confirm this using your example and you are 100% correct (according to gcc).  I'll drop fne from the list.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
> --Jason<br>
><br>
>     >  # Add optimizations to handle the case where the result of a<br>
>     ternary is<br>
>     >  # compared to a constant.  This way we can take things like<br>
<br>
<br>
</div></div></blockquote></div><br></div></div>