On Oct 6, 2020, Richard Biener <richard.guent...@gmail.com> wrote: > On October 6, 2020 3:15:02 AM GMT+02:00, Alexandre Oliva <ol...@adacore.com> > wrote: >> >> This is a first step towards enabling the sincos optimization in Ada. >> >> The issue this patch solves is that sincos takes the type to be looked >> up with mathfn_built_in from variables or temporaries in which results >> of sin and cos are stored. In Ada, sin and cos are declared in an >> internal aux package, with uses thereof in a standard generic package, >> which ensures that the types are not what mathfn_built_in expects.
> But are they not compatible? They are, in that they use the same underlying representation, but they're distinct types, not associated with the same TYPE_MAIN_VARIANT. In Ada it's not unusual to have multiple floating-point types unrelated to each other, even if they share identical underlying representation. Each such type is a distinct type, in a similar sense that in C++ each struct type holding a single double field is a distinct type. Each such distinct FP type gets a different instantiation of Ada.Numerics.Generic_Elementary_Functions, just as a C++ template taking a parameter type would get different instantiations for such different struct types. Overall, it's a very confusing situation. We use these alternate types to declare the Sin and Cos functions imported from libm as intrinsics (separate patch I've written very recently, yet to be contributed), and they get matched to the libm intrinsics despite the distinct types, we issue calls to them, passing variables of the alternate types without explicit conversions, but when the sincos pass looks up the sincos/cexpi intrinsic, it uses the alternate type taken from the variable and fails, rather than the types declared as taken by the builtins. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer
