Przemyslaw Wirkus <przemyslaw.wir...@arm.com> writes:
> Hi,
>
> Recent 'support SVE comparisons for unpacked integers' patch extends
> operands of define_expands from SVE_FULL to SVE_ALL. This causes an ICE
> hence this PR patch.
>
> This patch adds this relaxation for:
> + reduc_<optab>_scal_<mode> and
> + arch64_pred_reduc_<optab>_<mode>
> in order to support extra modes. Missing modes were used in REDUC_MAX.
>
> Original PR snippet proposed to reproduce issue was only causing ICE for C++
> compiler (see pr98177-1 test cases). I've slightly modified original snippet 
> in
> order to reproduce issue on both C and C++ compilers. These are pr98177-2
> test cases.
>
> Bootstrap/regression test for AArch64 aarch64-elf and no issues.

This is a bug in the vectoriser: the vectoriser shouldn't generate
IFN_REDUC_MAX calls that the target doesn't support.

I think the problem comes from using the wrong interface to get the
index type for a COND_REDUCTION.  vectorizable_reduction has:

      cr_index_vector_type = build_vector_type (cr_index_scalar_type,
                                                nunits_out);

which means that for fixed-length SVE we get a V2SI (a 64-bit Advanced
SIMD vector) instead of a VNx2SI (an SVE vector that stores SI elements
in DI containers).  It should be using:

      cr_index_vector_type = get_same_sized_vectype (cr_index_scalar_type,
                                                     vectype_out);

instead.  Same idea for the build_vector_type call in
vect_create_epilog_for_reduction.

Thanks,
Richard

Reply via email to