This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch match.pd] Add a simplify rule for x * copysign (1.0, y);
- From: Michael Matz <matz at suse dot de>
- To: James Greenhalgh <james dot greenhalgh at arm dot com>
- Cc: "pinskia at gmail dot com" <pinskia at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 1 Oct 2015 17:43:15 +0200 (CEST)
- Subject: Re: [Patch match.pd] Add a simplify rule for x * copysign (1.0, y);
- Authentication-results: sourceware.org; auth=none
- References: <1443707835-6888-1-git-send-email-james dot greenhalgh at arm dot com> <9593201B-9298-4529-A4DA-41B5DD6DCBFE at gmail dot com> <20151001145126 dot GA3881 at arm dot com>
Hi,
On Thu, 1 Oct 2015, James Greenhalgh wrote:
> > > x * copysign (1.0, y)
> > >
> > > x ^ (y & (1 << sign_bit_position))
> >
> > Also I think this can only be done for finite and non trapping types.
>
> That may be well true, I swithered either way and went for no checks,
> but I'd happily go back on that and wrap this in something suitable
> restrictive if I need to.
I don't think that's necessary. copysign (1.0, y) is always 1.0 or -1.0,
even with y being a NaN or inf. Additionally copysign is allowed to not
signal even if y is a sNaN. That leaves only the form of x to doubt. If
x is inf all is well (multiplying by +-1.0 is defined and both sequences
get the same result), if x is NaN the result must be a NaN, and it is in
both cases. The catch is that strictly speaking (NaN * -1.0) needs to
deliver NaN, not -NaN (operations involving quiet NaNs need to provide
one of the input NaNs as result), and here both are not equivalent. OTOH
the sign of NaNs isn't specified, so I think we could reasonably decide to
not care about this case (it would have to be checked if the hardware
multiplication even follows that rule, otherwise it's moot anyway).
And yes, also on x86-64 cores the new sequence would be better (or at
least as good; the latency of xor[sp][sd] is less than or equal to mul),
but that only is the case if the arithmetic really happen in SSE
registers, not in integer ones, and this isn't the case right now. Hmpf.
Ciao,
Michael.