On Tue, Feb 02, 2021 at 11:06:33AM +0100, Richard Biener wrote:
> So I fear this only covers parts of the paths simplifications can
> end up used. Now one question is whether we want to allow
> "invalid" intermediate transforms if a final match makes it
> "valid" again. If not then doing the verification in
> gimple-match.c itself might be preferable. OTOH I think that
> most patterns should verify themselves - it's also odd that
> v << 1 >> 1 is supported but not v & vec-cst - we might want to
> require some basic support from targets. I realize the PR is
> one of the odd V1mode cases which we might want to support better
> during RTL expansion (or require targets to be more sane here).
>
> So in the end I don't like the patch much, not at this stage
> anyway.
I'm afraid we can't just ignore it for GCC 11, there are many passes after
veclower and we have hundreds of folders on vector ops and many of them can
just turn something that is handled into something that isn't, even with
normal vector types and not the corner cases. Not all targets support all
optabs...
What about a modification of the patch which instead of preventing the
simplifications clears PROP_gimple_lvec property and schedule another
veclower pass right before isel which would be only run if the property
isn't set (I think the -O0 version of the pass already works that way).
Jakub
