On Mon, Aug 25, 2025 at 09:13:58AM -0600, Sandra Loosemore wrote:
> 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?
Mostly this was discussed in depth at the OpenMP F2F meeting where this was
voted into the standard, including slides etc.
At that meeting based on external feedback from Jason Merrill it was even
changed so that declare variant is marking the base calls with name of
variant to be looked up (note, at that point, not at the call site) rather
than the previous design which marked the variant calls to be variants for
base.
> 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.
Users who don't want to mess with the details can just use declare simd
directive; if they want to use it only in some cases and in other cases call
something else, they can mix it up with declare variant, declare variant on
the base with variant having declare simd, just they can't use the simd
construct in the selector.
This simd handling was meant e.g. for users who want to write extra
optimized versions of the vectorized code in assembly or using say x86
intrinsics.
> > 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
That is not what should be done. The lookup should be done at the declare
variant declaration side, that is how the design has been since that
meeting. The compiler records the variants and later on just picks from
that list of variants based on the condition.
> 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.
Jakub
