Stephen Canon
2014-Aug-28 15:01 UTC
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
> On Aug 28, 2014, at 10:58 AM, Duncan Sands <duncan.sands at deepbluecap.com> wrote: > > Hi Stephen, > >>> In the case of fadd, given that "fadd x, -0.0" is always equal to x (same bit pattern), then "fadd x, undef" can be folded to "x" (currently it is folded to undef, which is wrong). This implies that it is correct to fold "fadd undef, undef" to undef. Actually is it true that "fadd x, -0.0" always has exactly the same bits as x, or does it just compare equal to x when doing floating point comparisons? >> >> fadd x, –0.0 always has the same bit pattern as x, unless: >> >> (a) x is a signaling NaN on a platform that supports them. > > because you get a trap?Because you either get a trap (if the invalid exception is unmasked), or the invalid flag is set and the result is a quiet NaN (much more common).>> (b) x is a quiet NaN on a platform that does not propagate NaN payloads (e.g. ARM with "default nan" bit set in fpscr). > > What do you get in this case?A NaN whose “payload” (i.e. the bits in what would be the significand field of a normal number) may be different from those of the input NaN.>> (c) x is +0.0 and the rounding mode is round down. > > So far rounding modes were always ignored in LLVM AFAIK.I believe you’re right about this, but it would be nice to not paint ourselves into a corner w.r.t. rounding modes. – Steve
Oleg Ranevskyy
2014-Aug-29 12:39 UTC
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
Hi, So, the result of "fadd x, -0.0" might have a bit pattern different from the one of "x" depending on the value of "x" and the target. If I get it right, the result does not necessarily compare equal to "x" in floating point comparisons. Does this mean that folding of the above fadd to "x" in InstructionSimplify is incorrect? Oleg>> On Aug 28, 2014, at 10:58 AM, Duncan Sands <duncan.sands at deepbluecap.com> wrote: >> >> Hi Stephen, >> >>>> In the case of fadd, given that "fadd x, -0.0" is always equal to x (same bit pattern), then "fadd x, undef" can be folded to "x" (currently it is folded to undef, which is wrong). This implies that it is correct to fold "fadd undef, undef" to undef. Actually is it true that "fadd x, -0.0" always has exactly the same bits as x, or does it just compare equal to x when doing floating point comparisons? >>> fadd x, –0.0 always has the same bit pattern as x, unless: >>> >>> (a) x is a signaling NaN on a platform that supports them. >> because you get a trap? > Because you either get a trap (if the invalid exception is unmasked), or the invalid flag is set and the result is a quiet NaN (much more common). > >>> (b) x is a quiet NaN on a platform that does not propagate NaN payloads (e.g. ARM with "default nan" bit set in fpscr). >> What do you get in this case? > A NaN whose “payload” (i.e. the bits in what would be the significand field of a normal number) may be different from those of the input NaN. > >>> (c) x is +0.0 and the rounding mode is round down. >> So far rounding modes were always ignored in LLVM AFAIK. > I believe you’re right about this, but it would be nice to not paint ourselves into a corner w.r.t. rounding modes. > > – Steve > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Owen Anderson
2014-Aug-29 17:55 UTC
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
LLVM does not (today) try to preserve rounding mode or sNaNs. The only remaining question is whether we should be trying to preserve NaN payloads. —Owen On Aug 29, 2014, at 5:39 AM, Oleg Ranevskyy <llvm.mail.list at gmail.com> wrote:> Hi, > > So, the result of "fadd x, -0.0" might have a bit pattern different from the one of "x" depending on the value of "x" and the target. > If I get it right, the result does not necessarily compare equal to "x" in floating point comparisons. > Does this mean that folding of the above fadd to "x" in InstructionSimplify is incorrect? > > Oleg > >>> On Aug 28, 2014, at 10:58 AM, Duncan Sands <duncan.sands at deepbluecap.com> wrote: >>> >>> Hi Stephen, >>> >>>>> In the case of fadd, given that "fadd x, -0.0" is always equal to x (same bit pattern), then "fadd x, undef" can be folded to "x" (currently it is folded to undef, which is wrong). This implies that it is correct to fold "fadd undef, undef" to undef. Actually is it true that "fadd x, -0.0" always has exactly the same bits as x, or does it just compare equal to x when doing floating point comparisons? >>>> fadd x, –0.0 always has the same bit pattern as x, unless: >>>> >>>> (a) x is a signaling NaN on a platform that supports them. >>> because you get a trap? >> Because you either get a trap (if the invalid exception is unmasked), or the invalid flag is set and the result is a quiet NaN (much more common). >> >>>> (b) x is a quiet NaN on a platform that does not propagate NaN payloads (e.g. ARM with "default nan" bit set in fpscr). >>> What do you get in this case? >> A NaN whose “payload” (i.e. the bits in what would be the significand field of a normal number) may be different from those of the input NaN. >> >>>> (c) x is +0.0 and the rounding mode is round down. >>> So far rounding modes were always ignored in LLVM AFAIK. >> I believe you’re right about this, but it would be nice to not paint ourselves into a corner w.r.t. rounding modes. >> >> – Steve >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Apparently Analagous Threads
- [LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
- [LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
- [LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
- [LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
- [LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef