Nicolai Hähnle via llvm-dev
2018-Mar-05 21:02 UTC
[llvm-dev] how to simplify FP ops with an undef operand?
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.
Sanjay Patel via llvm-dev
2018-Mar-06 15:23 UTC
[llvm-dev] how to simplify FP ops with an undef operand?
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. On Mon, Mar 5, 2018 at 2:02 PM, Nicolai Hähnle via llvm-dev < 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>> 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. > > _______________________________________________ > 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/ba1470cf/attachment.html>
Chris Lattner via llvm-dev
2018-Mar-06 21:25 UTC
[llvm-dev] 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>