On Tue, 27 Feb 2024, Jeff Law wrote: > > > On 2/27/24 06:53, Richard Biener wrote: > > 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). > ACK. I'll force those targets to regenerate their baselines. > > I hadn't read things too closely and just wanted to raise the issue that this > impacts additional targets w/o vector support. It sounds like it's largely > expected fallout.
No, I didn't expect it (well, kind-of but my own testing came up clean...). I'm going to try the extra patterns. Richard.
