This is the mail archive of the 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: [Committed] New function fold_builtin_abs

On Fri, 11 Jun 2004, Paolo Bonzini wrote:
> I have a patch to add the isnan builtin and lower it to ORDERED_EXPR
> (SAVE_EXPR (x), SAVE_EXPR (x)); shall I wait for this series of patches
> to end before submitting?

Some platforms, such as the IA-64, have special instructions to
implement "isnan".  Hence, I'm undecided if the lowering of "isnan"
to *UNORDERED_EXPR* is best done in "fold" or later during RTL
expansion.  Given that tree-ssa doesn't like SAVE_EXPRs, it might
be worthwhile lowering "fold_builtin_isnan" only if a SAVE_EXPR node
isn't required, i.e. for a *_DECLs, constant folding for constants.

Then during RTL expansion, we'll need to treat unordered(x,x) and
isnan(x) identically, checking the isnandfsi optabs first, and if
that fails emitting the unordered comparison.

Possibly, the IA-64 doesn't even need a special "isnandfsi" pattern
if it could support/special case "(UNORDERED (REG:DF x) (REG:DF x)"
using its "fclass.m" opcode.

I don't think my changes should interfere with your proposed "isnan"
patch, so feel free to post something to get the discussion going,
but I do think that "isnan" -> "unordered" is not always a win on
some platforms, and those targets need some thinking about.
I recall RTH had some opinions on canonicalization of isnan?


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