Stephen Canon
2014-Aug-28 12:35 UTC
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
On Aug 28, 2014, at 3:03 AM, Duncan Sands <duncan.sands at deepbluecap.com> wrote:> Hi Owen, > > On 27/08/14 19:06, Owen Anderson wrote: >> >>> On Aug 27, 2014, at 6:34 AM, Duncan Sands <duncan.sands at deepbluecap.com >>> <mailto:duncan.sands at deepbluecap.com>> wrote: >>> >>> I think you should try to get LLVM floating point experts involved, to find >>> out their opinion about whether LLVM should really assume that snans always trap. >>> >>> If they think it is fine to assume trapping, then you can fold any floating >>> point operation with an "undef" operand to "undef". >>> >>> If they think it is no good, then the existing folds that use this need to be >>> removed or weakened, though maybe another argument can be found to justify them. >> >> LLVM is used to target many platforms for which sNaNs do not trap, and indeed >> many platforms that do not have floating point exceptions at all. > > thanks for the info. All of the floating point folds that rely on snans trapping should be corrected then. > > 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. (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). (c) x is +0.0 and the rounding mode is round down. – Steve
Duncan Sands
2014-Aug-28 14:58 UTC
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
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?> (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?> (c) x is +0.0 and the rounding mode is round down.So far rounding modes were always ignored in LLVM AFAIK. Note that LLVM folds "fadd x, -0.0" to x (in InstructionSimplify), which made me think of exploiting this for the undef case. Ciao, Duncan.
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
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