This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: PR29335 use MPFR for builtins fma, fmin and fmax
- From: Roger Sayle <roger at eyesopen dot com>
- To: "Kaveh R. GHAZI" <ghazi at caip dot rutgers dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 9 Nov 2006 20:12:30 -0700 (MST)
- Subject: Re: [PATCH]: PR29335 use MPFR for builtins fma, fmin and fmax
On Tue, 7 Nov 2006, Kaveh R. GHAZI wrote:
> 2006-11-04 Kaveh R. Ghazi <firstname.lastname@example.org>
> * builtins.c (do_mpfr_arg3): New.
> (fold_builtin_1): Handle builtins fma, fmin and fmax.
> * gcc.dg/torture/builtin-math-2.c: Test builtin fma.
> * gcc.dg/torture/builtin-math-3.c (CKSGN_F, CKSGN, CKSGN_L):
> New macros. Use them in exact tests.
> (TESTIT3): New macro.
> Add tests for fmin, fmax and fma.
This is OK for mainline. Thanks.
I'm not exactly sure what the official middle-end position on
min(0.0,-0.0) and max(0.0,-0.0) is. I know that Java requires
the sign to be taken into consideration, but I'm unsure whether
we require this of the backend-provided min?f3/max?f3 optabs or
of the RTL we expand if a min/max optab isn't available. I've
not checked but I've a suspicion that we generate a<b?a:b, and
therefore obtain an arbitrary sign.
Anyone have any opinions? I suspect that we may require different
semantics for the MIN_EXPR/MAX_EXPRs that we recognize via fold
and/or ifcvt.c, than we do for explicit calls to fmin/fmax.
For example, with a<b?a:b, we're not symmetric min(x,y) !== min(y,x).
At least, everything comes out OK when using -ffast-math! :-)