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