On Sun, Dec 21, 2025 at 10:52 AM Arsen Arsenović
<[email protected]> wrote:
>
> Richard Biener <[email protected]> writes:
>
> > ISTR the functions used so further down we can select an appropriate other
> > built in which name depends on the type. If this isn’t done here there’s no
> > reason to use this function at all. If it is, then using the lhs type is
> > wrong. What about simply failing if the function returns NULL?
>
> The effect of the patch as-is is effectively that; in cases when the
> IFNs for sin and cos are used, they're applied to vector types, which
> mathfn_built_in will return null for.
>
> I initially considered just skipping calls to IFNs entirely, because
> inevitably mathfn_built_in will fail on types those are used for, but I
> didn't want to bake that assumption in too deeply.
So the function does eventually do
/* Simply insert cexpi at the beginning of top_bb but not earlier than
the name def statement. */
fndecl = mathfn_built_in (type, BUILT_IN_CEXPI);
if (!fndecl)
which looks at
mtype = TYPE_MAIN_VARIANT (type);
if (mtype == double_type_node)
return fcode;
else if (mtype == float_type_node)
return fcodef;
else if (mtype == long_double_type_node)
return fcodel;
...
so it will _not_ work with possibly "random" float types (from non-C-family
frontends, for example).
I'd say it is a bit unfortunate we have .SIN/.COS "early" and it would be
nice if mathfn_built_in_type would recognize the type based on the mode
of the argument(!) as RTL expansion would. But I'd say returning false
is the more appropriate thing to do for now in tree-ssa-math-opts.cc
Richard.
> --
> Arsen Arsenović
