# Details

- Reviewers
spatel arsenm kpn craig.topper andrew.w.kaylor - Commits
- rGb51a90a0e30a: Teach InstSimplify -X + X --> 0.0 about unary FNeg

rL360777: 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

# 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.