Details
- Reviewers
spatel arsenm kpn craig.topper andrew.w.kaylor - Commits
- rZORGb51a90a0e30a: Teach InstSimplify -X + X --> 0.0 about unary FNeg
rZORGca061c5ef0be: Teach InstSimplify -X + X --> 0.0 about unary FNeg
rGb51a90a0e30a: Teach InstSimplify -X + X --> 0.0 about unary FNeg
rGca061c5ef0be: Teach InstSimplify -X + X --> 0.0 about unary FNeg
rG0c82d9b5a2e2: Teach InstSimplify -X + X --> 0.0 about unary FNeg
rL360777: Teach InstSimplify -X + X --> 0.0 about unary FNeg
Diff Detail
- Repository
- rL LLVM
Event Timeline
Is this an allowed transform?
If we transform "y = -x + x;" into "y = 0;" then won't that eliminate a trap? Is that allowed?
We're not dealing with constrained ops in this transform, so assume no traps/exceptions.
If I recall, fneg is not a constrained intrinsic because an fneg will never itself trap.
But a transform of -inf+inf to zero would be invalid by the standard, would it not? Section 7.2 paragraph d? Do we have a way of noting strict conformance to IEEE is required/desired without constrained intrinsics?
That's right.
But a transform of -inf+inf to zero would be invalid by the standard, would it not? Section 7.2 paragraph d? Do we have a way of noting strict conformance to IEEE is required/desired without constrained intrinsics?
So this xform only happens under nnan. IEEE-754 specifies that FAdd(+inf,-inf) --> QNaN. I'm not certain about what LLVM does under nnan in all cases, but we've definitely already diverged from IEEE-754 if there are no NaNs.
Correct on -inf+inf, and (assuming no logic bugs) we do have basic IEEE conformance w/o constrained intrinsics. We've ruled the inf case out by using fast-math-flags (nnan) on the fadd. See code comment :
// With nnan: -X + X --> 0.0 (and commuted variant) // We don't have to explicitly exclude infinities (ninf): INF + -INF == NaN.