This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fold isnan to UNORDERED_EXPR


On Mon, 28 Jun 2004, Paolo Bonzini wrote:
> 2004-06-21  Paolo Bonzini  <bonzini@gnu.org>
>
> 	* builtins.c (fold_builtin_isnan): New.
> 	(fold_builtin_unordered_cmp): Fix commentary.
> 	(fold_builtin) <BUILTIN_ISNAN>: Call fold_builtin_isnan.
> 	* builtins.def (BUILTIN_ISNAN): New.

Hi Paolo,

I think its best to define these builtins using DEF_C99_BUILTIN as regular
functions, not just as a GCC extension called __builtin_isnan that uses
varargs.  This follows the existing BSD 4.3 definitions of these
functions, having an isnanf for floats, and an isnanl for long doubles.
I'd like to think of C99's isgreater and friends as unusual exceptions
where GCC has to use varargs to emulate a macro.  If ever we can avoid
this idiom, we should.

Instead, we'll have

int isnan(double);
int isnanf(float);
int isnanl(long double);

and whilst you're at it you might as well add the following to
builtins.def,

int isinf(double);
int isinff(float);
int isinfl(long double);

int finite(double);
int finitef(float);
int finitel(long double);

I believe that finite* needs to be defined as DEF_EXT_LIB_BUILTIN as
it wasn't ratified by the C99 folks.



Then, at least for constant arguments these functions should be folded
in fold_builtin_isnan, fold_builtin_isinf and fold_builtin_finite.  Your
current implementation builds an UNORDERED_EXPR tree first, and then
passes that to fold to handle constant arguments, allocating more memory
than necessary.


Finally, I'm still a bit unsure about canonicalizing isnan(x) to
unordered(x,x).  Not only am I not a fan of SAVE_EXPRs, but on platforms
without UNORDERED instructions, we'll be replacing a call to libm's
"isnan" which takes a single argument with a call to libgcc's __unord?f2
which takes two, increasing code size and degrading performance.

I'd prefer, at the tree-level atleast to go the other way, and canonicalize
unordered(x,x) as isnan(x), and then at RTL expansion time decide whether
we can use the unord_optab to implement this functionality or not.  Even
if unord_optab isn't available we can still add a REG_EQUAL note to the
"isnan" call_insn, so that the RTL optimizers understand the semantics.


Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]