<div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 25, 2020 at 10:13 AM Roman Lebedev <<a href="mailto:lebedev.ri@gmail.com" target="_blank">lebedev.ri@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Feb 25, 2020 at 6:04 PM Sanjay Patel <<a href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Feb 24, 2020 at 10:44 AM Nuno Lopes <<a href="mailto:nuno.lopes@ist.utl.pt" target="_blank">nuno.lopes@ist.utl.pt</a>> wrote:<br>
>><br>
>> > ----------------------------------------<br>
>> > Name: t1<br>
>> >  %r = fsub half 4.000000, undef<br>
>> >  ret %r<br>
>> > =><br>
>> >  ret undef<br>
>> >  %r = fsub half 4.000000, undef<br>
>> ><br>
>> > ERROR: Value mismatch<br>
>> ><br>
>> > Example:<br>
>> > half %r = NaN   [based on undef value]<br>
>> > Source value: NaN<br>
>> > Target value: #x8500 (-0.000076293945?)<br>
>> ><br>
>> ><br>
>> > @Nuno: is this a bug in alive?<br>
>><br>
>> What Alive is trying to say is that there's no value x that makes "4.0 - x" yield the number 0x8500.<br>
>> I think Alive is correct here. FP operations usually can't produce the whole range of bit-patterns.<br>
><br>
><br>
> That was my conclusion from the review discussion and what I was hinting at in the commit message.<br>
><br>
> So this Alive example that includes "nnan" is incorrect IIUC:<br>
><br>
> %r = fsub nnan half 4.000000, undef<br>
>  ret %r<br>
> =><br>
>  ret undef<br>
><br>
> Optimization is correct!<br>
><br>
> ...because the "nnan" does not change the fact that we can't produce the entire range of FP bit-patterns.<br>
That wouldn't be my personal take on this, based on how i'd understand<br>
`nnan` from<br>
<a href="https://llvm.org/docs/LangRef.html#fast-math-flags" rel="noreferrer" target="_blank">https://llvm.org/docs/LangRef.html#fast-math-flags</a><br>
  No NaNs - Allow optimizations to assume the arguments and result are not NaN.<br>
  If an argument is a nan, or the result would be a nan, it produces a<br>
poison value instead.<br>
<br>
I.e. roughly i read this as: undef can be defined to a NaN constant,<br>
but then since 'nnan' is specified, the result is poison which we opt<br>
to relax into 'undef'.<br>
But i may be missing some fineprint.<br></blockquote><div><br></div><div>Ah, I was missing that chain of transforms: undef -> nan (but we have "nnan"!) -> poison -> undef.</div><div>It means that we can relax any FP undef folding to undef with -ffinite-math-only (or the larger -ffast-math).</div><div>Not sure if that's going to conflict with any existing transforms, but it's probably worth adding to help vector code.<br></div><div> </div></div></div>
</div>