This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR71078] x / abs(x) -> copysign (1.0, x)
On Mon, 1 Aug 2016, Joseph Myers wrote:
> On Mon, 1 Aug 2016, Richard Biener wrote:
>
> > On Mon, 1 Aug 2016, Joseph Myers wrote:
> >
> > > On Mon, 1 Aug 2016, Richard Biener wrote:
> > >
> > > > I don't think so - the pattern is as much a canonicalization as an
> > > > optimization. If the target cannot expand copysign then the
> > > > middle-end expander should try an alternative like the a / abs(x)
> > > > form. Though if copysign cannot be open-coded then I don't see
> > > > how abs can be opencoded (which basically is copysign (1.0, x)).
> > >
> > > It's expanded incorrectly in those cases (see bug 29253).
> >
> > Heh, looks like I worked on this 8 years ago...
> >
> > Fixing the copysign expansion issue should be as easy as
> > making sure expand_copysign_absneg is not used if the mode
> > has signed zeros.
>
> Correct expansion of abs or copysign for IBM long double (i.e., for the
> case where signbit_rw for the format is -1) requires special logic for
> that format; inhibiting particular incorrect expansion code may cause an
> external function call to be used in place of an incorrect inline
> expansion, but that won't help if you care about avoiding such a function
> call to fabsl or copysignl. The logic for IBM long double isn't that
> complicated - a few bitwise manipulations - but we don't have it at
> present (for that soft-float case).
So I read your comment as a general remark and not as an objection
to the patch in question?
Richard.