[PATCH][GCC][PR target/98177] aarch64: SVE: ICE in expand_direct_optab_fn

Richard Sandiford richard.sandiford@arm.com
Wed Dec 16 12:49:32 GMT 2020


Przemyslaw Wirkus <Przemyslaw.Wirkus@arm.com> writes:
> > 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.

Note that for this last bit I meant:

      tree vectype_unsigned = build_vector_type
	(scalar_type_unsigned, TYPE_VECTOR_SUBPARTS (vectype));

which should become:

      tree vectype_unsigned = get_same_sized_vectype (scalar_type_unsigned,
						      vectype);

This is the “transform” code that partners the “analysis” code that
you're patching.  Changing one but not the other would cause problems
if (say) the Advanced SIMD REDUC_MAX patterns were disabled.  We'd then
correctly pick an SVE mode like VNx4SI when doing the analysis, but generate
an unsupported V4SI REDUC_MAX in vect_create_epilog_for_reduction.
That in turn would trip the kind of expand-time assert that was
reported in the PR, just for a different case.

It's better for the modes to match up anyway: we should use a VNx4SI
reduction when operating on SVE and a V4SI reducation when operating on
Advanced SIMD.  This is particularly true for big endian, where mixing
SVE and Advanced SIMD can involve a permute.

> diff --git a/gcc/testsuite/g++.target/aarch64/pr98177-1.C b/gcc/testsuite/g++.target/aarch64/pr98177-1.C
> new file mode 100644
> index 0000000000000000000000000000000000000000..a776b7352f966f6b1d870ed51a7c94647bc46d80
> --- /dev/null
> +++ b/gcc/testsuite/g++.target/aarch64/pr98177-1.C
> @@ -0,0 +1,10 @@
> +/* { dg-do compile } */
> +/* { dg-options "-Ofast -march=armv8.2-a+sve -msve-vector-bits=128" } */
> +
> +int a, b;
> +short c;
> +void d(long e) {
> +  for (int f = 0; f < b; f += 1)
> +    for (short g = 0; g < c; g += 5)
> +      a = (short)e;
> +}

It'd be better to put these g++.target/aarch64/sve and drop the -march
option.  That way we'll test with the user's specified -march or -mcpu
if that -march/-mcpu already supports SVE.

Same idea for the other tests (including the C ones).

OK for trunk with those changes, thanks.

Richard


More information about the Gcc-patches mailing list