https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98287
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
Target Milestone|--- |10.3
Priority|P3 |P2
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r10-2805-ge944354ec05891474b0d204c6c239c04ee7b527b
I think this is another case of harmful folding after last veclower, in this
case during vrp2. After last veclower we need to be careful not to introduce
vector arithmetics that isn't supported by the target, as the expander doesn't
have fallback for that, it relies on tree-vect-generic.c doing its job.
So, either we need to guard all such match.pd etc. simplifications with checks
whether the operations are supported on the vectors if we are after last
veclower
- in this particular case it is the x >> 1 << 1 optimization to x & { ~1 },
where the backend announces V1DImode >> and << but not AND, or schedule another
veclower right before *.optimized dump to cover anything that got broken (or
before isel and hope isel doesn't fold things?), or add fallback to the
expander (the V1* vectors would be fairly easy, but anything else would be hard
and ugly).
