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.
