https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127850
Bug ID: 127850
Summary: [OpenMP] Handle user/manual-vectorization with SIMD
trait in 'declare variant'
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
This came up with PR 127734 (found via PR 127723):
Namely, 'declare variant(fvar) match(construct={simd(...)})
shall support manually handled vectorization functions by the user
not only taking care of the surrounding 'simd' construct or of
'declare simd'.
Cf. https://gcc.gnu.org/pipermail/gcc-patches/2026-October/734169.html
and https://gcc.gnu.org/pipermail/gcc-patches/2026-October/734175.html
>From the first email:
————————————————————————————
The intended behavior is that when simd isn't among the traits, we basically
take the arguments of the function and for the base look up (and instantiate
as needed) a function with the same argument types.
For simd, we should instead adjust the argument types depending on simdlen
and the chosen processor based on the Intel vector ABI (and other vector
ABIs derived from that one).
So, for declare variant without simd for function with int (int, long)
function type we look for function with int (int, long) time, while on
x86_64 if simdlen is 4 and it is notinbranch and it is the SSE2 case,
we should be looking up
int __attribute__((vector_size (4))) (int __attribute__((vector_size (4))),
long __attribute__((vector_size (2))),
long __attribute__((vector_size (2))))
function type instead (or instantiate it instead). So, basically look
at what function types we use when declare simd emits the specific variant
of the function, and look up the same argument types and compare the return
type.
So, using declare variant with simd is basically like doing manual
#pragma omp declare simd, user provides those functions instead of the
compiler though. And of course, it needs to be taken care of in the FEs
for the lookup and in the vectorizer too.
————————————————————————————
>From the second email:
————————————————————————————
I think supporting manual vectorized code via this makes sense. I presume
this is reflected in having, e.g., not 'int' but 'v4si' as function argument,
with 'typedef int v4si __attribute__ ((vector_size (16)));'
[…] On the other hand, I do not think there is anything wrong with supporting
it with 'declare simd' functions as well.
Additionally, I also do not see anything being wrong with using
match(construct={simd})
with a normal plan non-vectorized function. Admittedly, it is not really
useful - but I also do not see why it should be invalid, either.
Thus, at a glance, it seems as if we need:
* C++ lookup if the function / an overloaded function with the respective
vector arguments has been found - and check whether it matches.
* C/Fortran: lookup if that function matches with vector arguments.
If failing:
* Check with the original arguments - possibly printing a warning in that
case, unless it is 'declare simd' with the same simdlen length/divisor/type?
[…]
For Fortran, the non-'declare simd' variant will only work once manual
vectorization feature lands that was proposed at
https://conf.gnu-tools-cauldron.org/prg26/talk/L9WJP7/
————————————————————————————
For checking the arguments, the 'type' of the 'scaled' modifier to 'simdlen'
has be made available through a target hook to the front end such that it can
handle the checking (esp. for C++ overloading).
