https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96366
rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #1 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
---
(In reply to Bu Le from comment #0)
> Created attachment 48950 [details]
> preprocessed source code for recurent the problem
>
> Hi,
>
> The test case bb-slp-20.c in the gcc testsuit will cause an ICE in the
> expand pass because the gcc lack of a pattern for subtraction of the VNx2SI
> mode.
>
> The preprocessed file is attached and the problem will be triggered when
> compiled with -march=armv8.5-a+sve -msve-vector-bits=256 -O3
> -fno-tree-forwprop options.
>
> By tracing the debug infomation, it is found that the error is due to a
> vectorized subtraction gimple with VNx2SI mode cannot find its pattern
> during the expand pass.
Hmm. In general, the lack of a vector pattern shouldn't case ICEs,
but I suppose the add/sub pairing is somewhat special because of
the canonicalisation rules. It would be worth looking at exactly
why we generate the subtract though, just to confirm that this is
an “expected” ICE rather than a symptom of a deeper problem.
> I tried to extend the mode of this pattern from SVE_FULL_I to SVE_I as
> following, after which the problem is solved.
>
> diff -Nurp a/gcc/config/aarch64/aarch64-sve.md
> b/gcc/config/aarch64/aarch64-sve.md
> --- a/gcc/config/aarch64/aarch64-sve.md 2020-07-29 15:54:39.360000000 +0800
> +++ b/gcc/config/aarch64/aarch64-sve.md 2020-07-29 14:37:21.932000000 +0800
> @@ -3644,10 +3644,10 @@
> ;; -------------------------------------------------------------------------
>
> (define_insn "sub<mode>3"
> - [(set (match_operand:SVE_FULL_I 0 "register_operand" "=w, w, ?&w")
> - (minus:SVE_FULL_I
> - (match_operand:SVE_FULL_I 1 "aarch64_sve_arith_operand" "w, vsa,
> vsa")
> - (match_operand:SVE_FULL_I 2 "register_operand" "w, 0, w")))]
> + [(set (match_operand:SVE_I 0 "register_operand" "=w, w, ?&w")
> + (minus:SVE_I
> + (match_operand:SVE_I 1 "aarch64_sve_arith_operand" "w, vsa, vsa")
> + (match_operand:SVE_I 2 "register_operand" "w, 0, w")))]
> "TARGET_SVE"
> "@
> sub\t%0.<Vetype>, %1.<Vetype>, %2.<Vetype>
>
> I noticed that this mode iterator was changed from SVE_I to SVE_FULL_I in
> Nov 2019 by richard to support partial SVE vectors. However, in the
> following patch the addition pattern is supported by changing SVE_FULL_I to
> SVE_I but not the subtraction pattern. Is there any specific reason why this
> pattern is not supported?
The idea was for that patch to add the bare minimum needed
to support the “unpacked vector” infrastructure. Then, once the
infrastructure was in place, we could add support for other
unpacked vector operations too.
However, the infrastructure went in late during the GCC 10
cycle, so the idea was to postpone any new unpacked vector
support to GCC 11. So far the only additional operations
has been Joe Ramsay's patches for logical operations
(g:bb3ab62a8b4a108f01ea2eddfe31e9f733bd9cb6 and
g:6802b5ba8234427598abfd9f0163eb5e7c0d6aa8).
The reason for not changing many operations at once is that,
in each case, a decision needs to be made whether the
operation should use the container mode (as for INDEX),
the element mode (as for right shifts, once they're
implemented) or whether it doesn't matter (as for addition).
Each operation also needs tests. So from that point of view,
it's more convenient to have a separate patch for each
operation (or at least closely-related groups of operations).
