On 8/25/25 00:13, Jakub Jelinek wrote:
On Sun, Aug 24, 2025 at 08:16:32PM -0600, Sandra Loosemore wrote:
As noted in PR middle-end/121630, GCC seems to think that the "simd"
construct selector on "declare variant" implies that the variant
function accepts vectorized arguments, although this is not anywhere
in the OpenMP specification.
The intent has always been that the types will be transformed according to
the declare simd ABI rules, declare variant is meant to be in that case as a
way to optionally redirect calls to the vector ABI functions written by
hand. One needs to provide simdlen
If it has always been the intent that "declare variant" substitution
should do this SIMD replacement directly rather than it being a separate
transformation, can you come up with some references that say this, or
code examples outside the GCC test suite that are supposed to
demonstrate this behavior? I tried searching previously myself and
could not find anything, but OTOH I don't have access to the old OpenMP
design discussions and don't know what the committee might have been
thinking.
Just from reading the spec, my understanding (derived from the first two
bullet points at the bottom of p329 of the 6.0 spec) has been that the
construct selector acts an assertion that the variant function will only
be called in a matching context -- and therefore might be a candidate
for auto-annotation with "declare simd" and whatever else is implied by
the context, but *not* that users have to mess with the function
signature by hand to match what the compiler might or might not be doing
to transform it according to those attributes.
Yes, GCC doesn't have it implemented fully, but that doesn't mean it should
be ripped off, the implementation should be simply finished.
How? Declare variant substitution presently happens primarily during
gimplification which is way before any vectorization happens. And
fixing the various bugs esp in the C++ front end with regard to doing
the name lookup/template expansion/overload resolution using the actual
arguments at the call site will move the generation of the call_expr to
the variant even earlier, into the front ends. It seems like a very
poor design to me to be generating invalid calls to vector functions and
expecting them to be somehow fixed up later.
-Sandra
