Fix consistency of FP operators: add -> fadd, etc

[lattner]

Bugzilla Link	1285
Resolution	FIXED
Resolved on	Jun 12, 2009 14:39
Version	trunk
OS	All
CC	@efriedma-quic,@sunfishcode

Extended Description

As part of the signless types work, some FP operators were split out from the integer counterparts.
Because of this, we have fdiv/frem/fcmp, but some FP ops are still overloaded with integer ones (add/sub/
mul).

We should introduce explicit fadd/fsub/fmul operations, as well as a new unary fneg operator. This will
be important going forward, because we want to add flags to the various fp operations to support
"fastmath" and more FP pedantic languages.

-Chris

[llvmbot]

This sounds like a good idea, but I don't see a pressing need for it. In other
words, this seems like a lot of busy work for not much payoff.

Are we ready to get more pedantic with FP types? How about supporting
generalized FP types so we can define single/double/quad/intel 80bit etc. Seems
to me that this change would be more naturally aligned with better overall
support for FP math in LLVM.

[lattner]

I agree isn't not critical in the short-term.

Are we ready to get more pedantic with FP types? How about supporting
generalized FP types so we can define single/double/quad/intel 80bit etc.

The two issues are orthogonal. This bug is about better optimizing the types we have. We also need to
support new types :)

[efriedma-quic]

I think this is fixed, now that we have fadd, fsub, and fmul.

[sunfishcode]

LLVM still lacks a real fneg.

[lattner]

Do you plan to add it soon? If not, I suggest closing this bug and filing a new one for fneg.

[efriedma-quic]

Why exactly do we want fneg? Is there something wrong with just using fsub?

[lattner]

fneg != "-0.0 - x" in some rounding modes. This only really matters when we have rounding mode support in the IR, which is why I suggested deferring fneg.

[sunfishcode]

It's also not equivalent when x is NaN.

I opened llvm/llvm-bugzilla-archive#4378 to track the lack of fneg.

[lattner]

mentioned in issue llvm/llvm-bugzilla-archive#2831