On Oct 6, 2020, Richard Biener <richard.guent...@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
