Re: [PATCH] Fold isnan to UNORDERED_EXPR

[Paolo Bonzini <paolo dot bonzini at polimi dot it>]

> int isinf(double);
> int isinff(float);
> int isinfl(long double);
>
> int finite(double);
> int finitef(float);
> int finitel(long double);

These (especially isinf) are quite harder.  For example, finite can be 
defined as !isnan (x - x), but this maybe uselessly expensive.  Apart 
from cnstant folding, I don't easily see special expansions of isinf.

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

Ok.

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

Are there any, apart from maybe Alphas, which however are in not-IEEE 
mode by default?

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

I see.  Though this prevents from optimizing isnan (x) || isnan (y) to a 
single UNORDERED_EXPR.

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

What about recognizing the idiom UNORDERED_EXPR (x, x) in the RTL 
optimizers and expanding it to an isnan libcall?  rth objected "surely 
the other way" when you proposed folding UNORDERED_EXPR (x, x) to isnan 
(x), so I'm unsure about what to do.

Paolo