[llvm-dev] how to simplify FP ops with an undef operand?

[Nicolai Hähnle via llvm-dev]

On 05.03.2018 19:27, Sanjay Patel via llvm-dev wrote:
> 3. fadd C, undef --> undef (where C is not NaN or Inf)
> In the general constant case, the result could be anything as long as 
> constant operand C is not NaN or Inf.

If C is the largest finite positive number, then (fadd C, X) cannot be a 
finite negative number. So doesn't folding (fadd C, undef) --> undef 
break the rules?

Cheers,
Nicolai


> 
> 4. fadd NaN, undef --> NaN
> Same reasoning as #1; NaN propagates.
> 
> 5. fadd +/-Inf, undef --> NaN
> If the constant operand is +Inf or -Inf, then the result can only be 
> +Inf or -Inf unless the undef is NaN or the opposite Inf. If the undef 
> is NaN or opposite Inf, the result is NaN, so we choose undef as NaN and 
> propagate NaN. (If some program or known-bits is tracking that the 
> exponent bits are all set, we'll preserve that...)
> 
> See IEEE-754 section 7.2 for more rules.
> 
> 
> 
> On Sun, Mar 4, 2018 at 9:24 AM, Chris Lattner via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
> 
> 
>>     On Mar 3, 2018, at 1:55 PM, Steve (Numerics) Canon
>>     <scanon at apple.com <mailto:scanon at apple.com>> wrote:
>>
>>     On Mar 3, 2018, at 15:54, Chris Lattner <clattner at nondot.org
>>     <mailto:clattner at nondot.org>> wrote:
>>
>>>>     On Mar 2, 2018, at 8:31 AM, Stephen Canon <scanon at apple.com
>>>>     <mailto:scanon at apple.com>> wrote:
>>>>
>>>>     Thanks for expanding, Chris. Responses inline.
>>>>
>>>>>     On Mar 2, 2018, at 12:32 AM, Chris Lattner via llvm-dev
>>>>>     <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>>>
>>>>     <snip>
>>>>
>>>>>      - Because LLVM reorders and speculates the instruction forms,
>>>>>     and because IEEE defines the corresponding IEEE operations as
>>>>>     trapping on SNaNs, it is clear that SNaNs are outside of the
>>>>>     domain of these LLVM operations.  Either speculation is ok or
>>>>>     trapping on SNaN is ok, pick one…  (and we already did :) 
>>>>
>>>>     I see the source of confusion now.
>>>>
>>>>     IEEE does not define any operations as trapping on sNaN. It
>>>>     defines operations as raising the invalid flag on sNaN, which is
>>>>     *not a trap* under default exception handling. It is exactly the
>>>>     same as raising the underflow, overflow, inexact, or
>>>>     division-by-zero flag.
>>>>
>>>>     Any llvm /instruction/ necessarily assumes default exception
>>>>     handling—otherwise, we would be using the constrained intrinsics
>>>>     instead. So there’s no reason for sNaN inputs to ever be undef
>>>>     with the llvm instructions. They are just NaNs.
>>>
>>>     Ah yes, I completely misunderstood that!  Thank you for
>>>     clarifying.  In that case, it seems perfectly reasonable for
>>>     “fadd undef, 1” to fold to undef, right?
>>
>>     Yes, indeed.
> 
>     Great! Can someone please update LangRef so we codify this for the
>     next time I forget? :-)
> 
>     -Chris
> 
> 
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 


-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.