[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671

--- Comment #18 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #17)
> (In reply to ktkachov from comment #16)
> > (In reply to Jakub Jelinek from comment #15)
> > > Yeah, my preference is to back out the cse.c one-liner for GCC 6.
> > 
> > IMO the cse.c patch is the correct fix for the code quality regression seen
> > on the gcc.target/arm/wmul-1.c and gcc.target/arm/wmul-2.c tests on arm when
> > tuning for -mcpu=cortex-a9, which is a fairly popular arm target.
> 
> While it may be a correct fix, IMHO it is not appropriate for this late in
> the release cycle.
> 
> > The patch didn't have a performance impact on SPEC2000 and SPEC2006 on arm,
> > but I did see the adverse code quality effect from gcc.target/arm/wmul-1.c
> > and gcc.target/arm/wmul-2.c on a popular embedded benchmark without it.
> > 
> > So reverting this would cause performance regressions on some normal integer
> > code on arm (not using intrinsics).
> > 
> > How risky at this stage is it to do the define_subst fix for the AVX
> > patterns?
> 
> It affects lots of patterns in the i?86 backend, just grep for 0C
> constraints, especially the subst.md use adds it to most of the vector
> instructions even when they don't have it explicitly.  So, it is very risky
> to change those now.

Ok, if that's the case then we should XFAIL the gcc.target/arm/wmul-1.c and
gcc.target/arm/wmul-2.c tests and fix the AVX patterns for GCC 7 so that the
cse.c change can go in for that release.