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: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: James Greenhalgh <james dot greenhalgh at arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 2 Oct 2015 11:03:58 +0200
- 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> <20151001183643 dot GD28276 at tucnak dot redhat dot com> <CAFiYyc1FTirc+cgo1fmqanNRDw=iXSN2uH6LjEaj7yGyr1isqA at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Oct 02, 2015 at 10:18:01AM +0200, Richard Biener wrote:
> On Thu, Oct 1, 2015 at 8:36 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Thu, Oct 01, 2015 at 02:57:15PM +0100, James Greenhalgh wrote:
> >> 2015-10-01 James Greenhalgh <james.greenhalgh@arm.com>
> >>
> >> * match.pd (mult (COPYSIGN:s real_onep @0) @1): New simplifier.
> >
> > Also, please note that
> > + wide_int m = wi::min_value (TYPE_PRECISION (type), SIGNED);
> > + tree tt
> > + = build_nonstandard_integer_type (TYPE_PRECISION (type),
> > + false);
> > + tree mask = wide_int_to_tree (tt, m);
> > is really not a reliable way to determine which bit to change.
> > In some floating format it is not possible at all, in others it might not
> > be the topmost bit of the precision, or might depend on
> > FLOAT_WORDS_BIG_ENDIAN etc., see expand_copysign_bit and expand_copysign
> > for details (e.g. one has to look at fmt->signbit_rw etc.).
> > So, I probably agree with Andrew that it would be better optimized during
> > expansion. One issue for that though is that TER stops at calls, we'd need
> > to special case this case.
>
> I agreee with optimizing this in expansion only. The copysign form is shorter
> and it captures the high-level part of the operation better. Say we later
> constant-propagate a positive real into y then chances are high we optimize
> the copysign form but not the lowered one. Also if we ever get VRP to
> handle real-type ranges it would need to decipher the sequence as well.
But hacking TER for this special case might not be nice either, perhaps
we want an internal function that would represent this
- CHANGESIGN (x, y) -- (x * copysign (1.0, y)) (or some better name) and
fold this say during fab pass or so, and then let expansion decide how exactly to
expand it (custom optab, or the generic tweaking of the bit, something else?).
BTW, it seems wrf also in many places uses MAX <copysign (1.0, y), 0.0>
or MIN <copysign (1.0, y), 0.0> (always in pairs), would that be also
something to optimize?
Also, the x * copysign (1.0, y) in wrf is actually x * (1/12.) * copysign (1.0, y)
(or similar - other constants), wouldn't it make more sense to optimize that
as x * copysign (1/12., y) first (at least if we can reassociate)?
Jakub