https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118377
--- Comment #8 from ktkachov at gcc dot gnu.org ---
(In reply to Tejas Belagod from comment #7)
> Sorry for the delay in replying. Though variable-length(VLA) SVE vector
> types behave as GNU vectors for C/C++ operator semantics, there is currently
> no support for decomposing them into scalar operation sequences if no native
> support exists.
>
> For this test case, fixed length SVE vectors(eg. -msve-vector-bits=256)
> compile fine because the div is optimized into a sequence of shifts and
> adds. This optimization is currently only supported for fixed-size vectors
> (expand_vector_divmod ()) and even if we do end up supporting VLA vector
> types for this optimization, we'd have to fallback to piecewise operation if
> the optimization is unsuccessful for which the support doesn't exist.
> Therefore, I think it's best to diagnose and reject such types' operations
> in the FE as unsupported by the target.
There are tricks the compiler can do to handle these ops. For example Clang can
handle:
#include <arm_sve.h>
svint16_t
foo (svint16_t x, svint16_t y)
{
return x / y;
}
by generating:
foo:
sunpkhi z2.s, z1.h
sunpkhi z3.s, z0.h
ptrue p0.s
sunpklo z1.s, z1.h
sunpklo z0.s, z0.h
sdivr z2.s, p0/m, z2.s, z3.s
sdiv z0.s, p0/m, z0.s, z1.s
uzp1 z0.h, z0.h, z2.h
ret
In Soumya's original case (dividing an svint16_t by 4) it can generate:
foo:
ptrue p0.h
asrd z0.h, p0/m, z0.h, #2
ret
It can certainly get quite involved so teaching GCC to do that is likely not
feasible for GCC 15 and adding a sorry or rejection in these cases may be
appropriate.
But in the longer term it would be good to have GCC and Clang accept the same
things unless the ACLE spec itself restricts the allowable operators.
