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
----------------------------------------------------------------------------
Last reconfirmed| |2020-07-31
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #3 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
---
(In reply to Bu Le from comment #2)
> (In reply to rsand...@gcc.gnu.org from comment #1)
> > (In reply to Bu Le from comment #0)
> > 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.
>
> Sure. The logic is that the subtraction will be expanded in expr.c:8989,
> before which I believe it still works fine. The gimple to be expand is
>
> vect__5.16_77 = { 4294967273, 4294967154, 4294967294, 4294967265 } -
> vect__1.14_73
Yeah. What I was worried about was: why did we generate this
in the first place if the target doesn't support it?
But it looks like the answer is that, after
g:bb3ab62a8b4a108f01ea2eddfe31e9f733bd9cb6, SVE now advertises
support for both unpacked addition *and* unpacked negation.
Initially we generate a supported vector negation:
vect_a0_52.15_78 = vect__1.14_73 + { 23, 142, 2, 31 };
vect__5.16_77 = -vect_a0_52.15_78;
and this later gets folded into the subtraction above.
Before the patch there was no ICE.
Generating a subtraction out of an addition seemed odd since
canonicalisations usually go the other way. But if the target
says it supports negation too then that changes things. It doesn't
make much sense to support addition and negation but not subtraction.
I think that's enough to show that the patch to the .md file
is the right fix and isn't papering over a problem elsewhere.
Could you post it to gcc-patches?
