On Tue, Oct 6, 2020 at 11:34 AM Alexandre Oliva <ol...@adacore.com> wrote: > > 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.
Yes, I understand. > 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. Ah, we eventually already do that. So how about that mathfn_type helper instead of hard-wring this logic in sincos()? Richard. > > -- > Alexandre Oliva, happy hacker > https://FSFLA.org/blogs/lxo/ > Free Software Activist > GNU Toolchain Engineer
