Am 25.08.25 um 08:13 schrieb Jakub Jelinek:
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.
It does imply that.
I am not sure that the spec implies this, but it permits it. And there
are hints in the spec that members of the language committee intended
that it will work like ...
it has always been the intent when declare simd
has been introduced that simd trait will be treated like that on compilers
with some kind of vector ABI and the reason why various simd related
restrictions exist for declare variant:
* * *
Yes, GCC doesn't have it implemented fully, but that doesn't mean it should
be ripped off, the implementation should be simply finished.
I have to admit that it is not completely clear to me when/whether
'declare variant' should just used a used-vectorized function vs.
SIMD-izing a function; and, for the latter, how this is supposed to
get handled when in the 'declare variant' TU is only a declaration
and not the definition.
As the word "implementation defined" appears, I guess we eventually
need to document this. (As the spec requires this for implementation
defined features, contrary to unspecified ones.)
Looking at the examples, I only found one pattern (4 tests):
c-c++-common/gomp/declare-variant-5.c has:
__v4si f1 (__v4sf, __v4sf, float *);
__v8si f2 (__v8sf, __v8sf, float *);
#pragma omp declare variant (f1) match
(construct={parallel,for,simd(simdlen(4),notinbranch,uniform(z),aligned(z:4 *
sizeof (*z)))})
#pragma omp declare variant (f2) match
(construct={for,simd(uniform(z),simdlen(8),notinbranch)})
int f4 (float x, float y, float *z);
Similar Fortran version: gcc/testsuite/gfortran.dg/gomp/declare-variant-5.f90
And, test to check that there is no ICE:
gcc/testsuite/gcc.dg/gomp/pr95315-2.c
The variant-5 test requires/uses AXV2 but the variants do not seem to get used
at all - and all tests only check that compilation works (no errors, no ICEs),
but do not have any check on the resulting code (dumps, assembler).
* * *
It seems as if we need a problem report to track the missing functionality.
It is not quite clear to me whether we can run into code which is invalid
(at least when assuming that base function and the SIMD function give the
same result) - or not.
If we do, we need to add some 'sorry' - and some comments (pointing to the PR)
IMHO won't harm at all.
It seems as if there the following combinations:
* 'declare simd' + 'declare variant'
* only 'declare variant' using a non-vector and a vector version as variant
* append_args/adjust_args
* For the latter two and 'declare simd': As both a mask-free and mask version
exists, append_args and esp. adjust_args with numeric argument (variadic)
need to operate on the right argument.
If any of those do not work but would apply, we need a sorry - and either way,
we need to mention those in the PR.
Tobias
