llvm dev - Mar 2018 - how to simplify FP ops with an undef operand?

> On Mar 6, 2018, at 7:23 AM, Sanjay Patel via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I need to review the last thread about undef/poison (or someone who knows
current status of that can reply), but this would seem to come down to whether
undef applies to the entire value or the individual bits?
> Ie, in your example the sign bit will never be set unless all of the
exponent bits are also set. Each bit individually is unknown, but taken together
we know that some sequences are impossible.
The “on the ground” reason we made undef be a bit-level concept for integers was
specific problems with C bitfields: when initializing a mem2reg’d bitfield, you
end up doing or’s into undef values, and those bits have to be defined.

I’m not aware of a similar concept that makes sense for fp values.  We could
choose to do fine grain tracking (e.g. so ldexp and friends would work to set
the exponent??) but I don’t see any practical reason for doing so.

-Chris

> 
> On Mon, Mar 5, 2018 at 2:02 PM, Nicolai Hähnle via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 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> <mailto: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>
<mailto: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>
>     <mailto: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>
>     <mailto: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> <mailto: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>
<mailto: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>
>     <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 <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>
> 
> 
> 
> -- 
> Lerne, wie die Welt wirklich ist,
> Aber vergiss niemals, wie sie sein sollte.
> 
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/4577ff6c/attachment.html>

> On Mar 6, 2018, at 4:25 PM, Chris Lattner via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> 
>> On Mar 6, 2018, at 7:23 AM, Sanjay Patel via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> I need to review the last thread about undef/poison (or someone who
knows current status of that can reply), but this would seem to come down to
whether undef applies to the entire value or the individual bits?
>> Ie, in your example the sign bit will never be set unless all of the
exponent bits are also set. Each bit individually is unknown, but taken together
we know that some sequences are impossible.
> 
> The “on the ground” reason we made undef be a bit-level concept for
integers was specific problems with C bitfields: when initializing a mem2reg’d
bitfield, you end up doing or’s into undef values, and those bits have to be
defined.
> 
> I’m not aware of a similar concept that makes sense for fp values.  We
could choose to do fine grain tracking (e.g. so ldexp and friends would work to
set the exponent??) but I don’t see any practical reason for doing so.
I agree. Tracking the signbit might be interesting sometimes, but it’s a
second-order effect.

– Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/19151739/attachment.html>

For reference, some patches based on this discussion:
https://reviews.llvm.org/D44258
https://reviews.llvm.org/D44216
https://reviews.llvm.org/D44308
https://reviews.llvm.org/D44318

Thanks to all for your help cleaning this up.


On Tue, Mar 6, 2018 at 2:27 PM, Stephen Canon <scanon at apple.com> wrote:
>
>
> On Mar 6, 2018, at 4:25 PM, Chris Lattner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
>
> On Mar 6, 2018, at 7:23 AM, Sanjay Patel via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> I need to review the last thread about undef/poison (or someone who knows
> current status of that can reply), but this would seem to come down to
> whether undef applies to the entire value or the individual bits?
> Ie, in your example the sign bit will never be set unless all of the
> exponent bits are also set. Each bit individually is unknown, but taken
> together we know that some sequences are impossible.
>
>
> The “on the ground” reason we made undef be a bit-level concept for
> integers was specific problems with C bitfields: when initializing a
> mem2reg’d bitfield, you end up doing or’s into undef values, and those bits
> have to be defined.
>
> I’m not aware of a similar concept that makes sense for fp values.  We
> could choose to do fine grain tracking (e.g. so ldexp and friends would
> work to set the exponent??) but I don’t see any practical reason for doing
> so.
>
>
> I agree. Tracking the signbit might be interesting sometimes, but it’s a
> second-order effect.
>
> – Steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180309/05819459/attachment.html>