On Tue, 27 Feb 2024, Jeff Law wrote:
>
>
> On 2/27/24 00:43, Richard Biener wrote:
> > On Tue, 27 Feb 2024, haochen.jiang wrote:
> >
> >> On Linux/x86_64,
> >>
> >> af66ad89e8169f44db723813662917cf4cbb78fc is the first bad commit
> >> commit af66ad89e8169f44db723813662917cf4cbb78fc
> >> Author: Richard Biener <rguent...@suse.de>
> >> Date: Fri Feb 23 16:06:05 2024 +0100
> >>
> >> middle-end/114070 - folding breaking VEC_COND expansion
> >>
> >> caused
> >>
> >> FAIL: gcc.dg/tree-ssa/andnot-2.c scan-tree-dump-not forwprop3 "_expr"
> >
> > This shows that the x86 backend is missing vcond_mask_qiqi and friends
> > (for AVX512 mask modes). Either that or both expand_vec_cond_expr_p
> > and all the machinery behind it (ISEL pass, lowering) should handle
> > pure integer mode VEC_COND_EXPR via bit operations. I think quite some
> > targets now implement patterns for these variants, whatever their
> > boolean vector modes are.
> There may be more going on than just that. The andnot-2 test started
> regressing on most targets overnight, including on targets without vector
> capabilities.
Yes, we fail this generic vector simplification test now (not sure
why the test didn't test forwprop1). As said the problem is that
we can't test whether the existing VEC_COND_EXPR is handled
(we just can test if it's handled by vcond_mask).
As can be seen from x86 we don't want to turn the existing working
vcond into unsupported vcond_mask as that will fail to expand
(that's what the patch fixed for SPARC) or similarly bad, would
be lowered during vector lowering into inefficient scalar code.
In the end this is fallout from splitting out the condition from
VEC_COND_EXPR but not getting rid of all vcond{,u,eq} expanders,
rewriting target support to vcmp{,u,eq} + vcond_mask ... (those partial
transitions...).
Grepping shows there's unfortunately plenty of targets with
vcond{,u,eq} patterns, maybe most of them have vcmp{,u,eq}
patterns as well but only cutting those off hard by simply
removing the expansion path will tell who's affected.
One could try to fix this by adding a 2nd set of patterns where
the defining conditionals are visible, so we can check for
vcond[u] expansion support (and compare before/after state),
and allow the patterns w/o visible compares only when vcond_mask
is available.
Richard.
> fr30-elf for example:
>
>
> > Tests that now fail, but worked before (2 tests):
> >
> > fr30-sim: gcc: gcc.dg/tree-ssa/andnot-2.c scan-tree-dump-not forwprop3
> > "_expr"
> > fr30-sim: gcc: gcc.dg/tree-ssa/andnot-2.c scan-tree-dump-not forwprop3
> > "_expr"
>
>
> Jeff
