This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fold (a > 0 ? 1.0 : -1.0) into copysign (1.0, a) and a * copysign (1.0, a) into abs(a)
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Richard Sandiford <richard dot sandiford at linaro dot org>
- Cc: Marc Glisse <marc dot glisse at inria dot fr>, Andrew Pinski <pinskia at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 26 Jun 2017 15:22:03 +0000
- Subject: Re: [PATCH] Fold (a > 0 ? 1.0 : -1.0) into copysign (1.0, a) and a * copysign (1.0, a) into abs(a)
- Authentication-results: sourceware.org; auth=none
- References: <CA+=Sn1m-pMkB1Vvoi3s_N0DSwLioB3T90778oSDQNOYME83txA@mail.gmail.com> <alpine.DEB.firstname.lastname@example.org> <email@example.com>
On Mon, 26 Jun 2017, Richard Sandiford wrote:
> > Non-generic builtins like copysign are such a pain... We also end up
> > missing the 128-bit case that way (pre-existing problem, not your patch).
> > We seem to have a corresponding internal function, but apparently it is
> > not used until expansion (well, maybe during vectorization).
> It should be OK to introduce uses of the internal functions whenever
> it's useful. The match code will check that the internal function is
> implemented before allowing the transformation.
How well would internal functions work with some having built-in functions
only for float, double and long double, others (like copysign) having them
for all the _FloatN and _FloatNx types?
(Preferably of course the built-in functions for libm functions would
generally exist for all the types. I didn't include that in my patches
adding _FloatN/_FloatNx support
<https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01442.html> and noted
various issues to watch out for there, especially increasing the size of
the enum of built-in functions and the startup cost of initializing them.
There are other optimizations with similar issues of only covering float,
double and long double.)
Joseph S. Myers