On Tue, Aug 31, 2021 at 11:11 AM Kewen.Lin via Gcc <gcc@gcc.gnu.org> wrote: > > on 2021/8/30 下午10:11, Bill Schmidt wrote: > > On 8/30/21 8:04 AM, Florian Weimer wrote: > >> There has been a discussion, both off-list and on the gcc-help mailing > >> list (“Why vectorization didn't turn on by -O2”, spread across several > >> months), about enabling the auto-vectorizer at -O2, similar to what > >> Clang does. > >> > >> I think the review concluded that the very cheap cost model should be > >> used for that. > >> > >> Are there any remaining blockers? > > > > Hi Florian, > > > > I don't think I'd characterize it as having blockers, but we are continuing > > to investigate small performance issues that arise with very-cheap, > > including some things that regressed in GCC 12. Kewen Lin is leading that > > effort. Kewen, do you feel we have any major remaining concerns with this > > plan? > > > > Hi Florian & Bill, > > There are some small performance issues like PR101944 and PR102054, and > still two degraded bmks (P9 520.omnetpp_r -2.41% and P8 526.blender_r > -1.31%) to be investigated/clarified, but since their performance numbers > with separated loop and slp vectorization options look neutral, they are > very likely noises. IMHO I don't think they are/will be blockers. > > So I think it's good to turn this on by default for Power. The intel side is also willing to enable O2 vectorization after measuring performance impact for SPEC2017 and eembc. Meanwhile we are investigating PR101908/PR101909/PR101910/PR92740 which are reported O2 vectorization regresses extra benchmarks on znver and kabylake. > > BR, > Kewen
-- BR, Hongtao
