<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 24, 2020 at 10:44 AM Nuno Lopes <<a href="mailto:nuno.lopes@ist.utl.pt">nuno.lopes@ist.utl.pt</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">> ----------------------------------------<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></blockquote><div><br></div><div>That was my conclusion from the review discussion and what I was hinting at in the commit message.</div><div><br></div><div>So this Alive example that includes "nnan" is incorrect IIUC:</div><div><br></div><div>%r = fsub nnan half 4.000000, undef<br>
 ret %r<br>
=><br>
 ret undef<br>
<br>
Optimization is correct!</div><div><br></div><div>...because the "nnan" does not change the fact that we can't produce the entire range of FP bit-patterns.<br></div><div> </div></div></div>