On 8/30/2021 9:30 PM, Hongtao Liu via Gcc wrote:
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.
We'd like to see it on for our processor as well. Though I don't have
numbers I can share at this time.
jeff
