llvm dev - Jun 2013 - [LLVMdev] round() vs. rint()/nearbyint() with fast-math

Hello,

Sometime over the last few months, I implemented in the PowerPC backend a
fast-math-only optimization which lowers ISD::FRINT/FNEARBYINT in terms of the
frin instruction (when supported). As one of my users has pointed out to me,
frin actually implements the semantics of round() [it ties away from zero]
instead of implementing nearbyint() [which ties to even]. This user has
additionally pointed out that LLVM on x86 does not lower round() in the same way
that it lowers rint() in fast-math mode.

LLVM does not currently have special lowering handling for round(), and I'll
propose a patch to add that, but the larger question is this: should fast-math
change the tie-breaking behavior of rint/nearbyint/round, etc. and, if so,
should we make a specific effort to have all backends provide the same guarantee
(or lack of a guarantee) in this regard?

Thanks again,
Hal

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

| LLVM does not currently have special lowering handling for round(), and
I'll propose a patch to add that, but the larger question is this: should
fast-math change the tie-breaking behavior of
| rint/nearbyint/round, etc. and, if so, should we make a specific effort to
have all backends provide the same guarantee (or lack of a guarantee) in
this regard?

I don't know, primarily because I've never really been involved in
anything
where I've cared about using exotic rounding modes. But in general I'm
of
the opinion that -fast-math is the "nuclear option" that's allowed
to do
lots of things which may well invoke backend specific behaviour. (That's
also why I think that most FP transformations shouldn't be "only"
guarded by
fast-math but a more precise option.)

Cheers,
Dave