Enable the vectorizer at -O2 for GCC 12

[Jeff Law]

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