make sincos take type from intrinsic formal, not from result assignment

Alexandre Oliva oliva@adacore.com
Tue Oct 6 09:34:06 GMT 2020


On Oct  6, 2020, Richard Biener <richard.guenther@gmail.com> wrote:

> OK, I see.  mathfn_built_in expects a type inter-operating with
> the C ABI types (float_type_node, double_type_node, etc.) where
> "inter-operating" means having the same main variant.

Yup.

> Now, I guess for the sincos pass we want to combine sinl + cosl
> to sincosl, independent on the case where the result would be
> assigned to a 'double' when 'double == long double'?

Sorry, I goofed in the patch description and misled you.

When looking at

  _d = sin (_s);

the sincos didn't take the type of _d, but that of _s.

I changed it so it takes the not from the actual passed to the
intrinsic, but from the formal in the intrinsic declaration.

If we had conversions of _s to different precisions, the optimization
wouldn't kick in: we'd have different actuals passed to sin and cos.
I'm not sure it makes much sense to try to turn e.g.

  _d1 = sin (_s);
  _t = (float) _s;
  _d2 = cosf (_t);

into:

  sincos (_s, &D1, &T);
  _d1 = D1;
  _td2 = T;
  _d2 = (float) _td2;

If someone goes through the trouble of computing sin and cos for the
same angle at different precisions, you might as well leave it alone.

> Now what about sinl + cos when 'double == long double'?

Now that might make more sense to optimize, but if we're going to do
such transformations, we might as well canonicalize the *l intrinsics to
the equivalent double versions (assuming long double and double have the
same precision), and then sincos will get it right.

-- 
Alexandre Oliva, happy hacker
https://FSFLA.org/blogs/lxo/
Free Software Activist
GNU Toolchain Engineer


More information about the Gcc-patches mailing list