Re: [PATCH] middle end, s390: optimization for builtin isnan

[Ian Lance Taylor <iant at google dot com>]

Wolfgang Gellerich <gellerich@de.ibm.com> writes:

> Ian Lance Taylor <iant@google.com> wrote on 07.08.2007 03:26:28:
> 
> > Wolfgang Gellerich<gellerich@de.ibm.com> writes:
> >
> > > This patch introduces a new target hook allowing to optimize the
> > > implementation of builtin function isnan on platforms like s390 where
> > > arithmetic operations set the condition code when the result was NaN.
> It
> > > bootstraps on Intel and s390 and does not introduce new test case
> failures.
> >
> > It seems to me that we should handle this by treating isnan as a unary
> > operator which may be implemented in the MD file.  E.g., implement
> > isnansf1 and isnandf1, with optabs.  I don't see why a target hook is
> > the right thing here.
> 
> Hi Ian, many for your comments! However, what would we gain from
> implementing isnan as operator, and what do you consider as major
> disadvantages of using the new target hook? The reason why I chose the
> implementation I sent is that the current implementation was hard-wired at
> a rather early stage. I thought that there might be a reason for this, it
> may enable further optimizations in some cases or on some platforms. Also,
> the target hook approach has the advantage that is allows s390 (and other
> platforms) to add their optimizations while not causing any changes for
> platforms that are happy with the current implementation.

Sorry, you're right, my suggestion doesn't make sense.  Still, I'm not
that fond of target-specific target hooks.  Also, it's not obvious to
me that your suggestion is always an improvement.  It's clearly an
improvement for your test case, but what happens when there is no
floating point operation to set the condition code?  As in
    foo (double x) { return isnan (x); }
Don't you wind up materializing a floating point zero in order to do
the comparison, thus adding an unnecessary instruction?

Looking at your e-mail more closely, I expect that what you want can
be handle with a define_split which runs at combine time.  You want
the split to recognize the three instructions
    adbr f2, f3
    cdbr f2, f2
    jo label
and combine them into simply
    adbr f2, f3
    jo label
This combination of three instructions into two is what combine-time
define_splits do.

Ian