Enable the vectorizer at -O2 for GCC 12

Enable the vectorizer at -O2 for GCC 12

[Florian Weimer]

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?

Thanks,
Florian

Re: Enable the vectorizer at -O2 for GCC 12

[Bill Schmidt]

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?

Thanks,
Bill

>
> Thanks,
> Florian
>

Re: Enable the vectorizer at -O2 for GCC 12

[Kewen.Lin]

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.

BR,
Kewen

Re: Enable the vectorizer at -O2 for GCC 12

[Hongtao Liu]

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

Re: 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

Re: Enable the vectorizer at -O2 for GCC 12

[Andrew Stubbs]

On 31/08/2021 05:13, Jeff Law wrote:
> 
> 
> 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.

AMD GCN probably ought to have it on too, possibly set to maximum ... a 
GPU without vectors is pretty terrible.

Andrew

RE: Enable the vectorizer at -O2 for GCC 12

[Tamar Christina]

-- edit, added list back in --

Just to add some AArch64 numbers for Spec2017 we see 2.1% overall Geomean improvements (all from x264 as expected) with no real regressions (everything within variance) and only a 0.06% binary size increase overall (of which x264 grew 0.15%) using the very cheap cost model.

So we'd be quite keen on this as well.

Cheers,
Tamar

> -----Original Message-----
> From: Gcc <gcc-bounces+tamar.christina=arm.com@gcc.gnu.org> On Behalf
> Of Florian Weimer via Gcc
> Sent: Monday, August 30, 2021 2:05 PM
> To: gcc@gcc.gnu.org
> Cc: jakub@redhat.com; Richard Earnshaw <Richard.Earnshaw@arm.com>;
> Segher Boessenkool <segher@kernel.crashing.org>; Richard Sandiford
> <Richard.Sandiford@arm.com>; Premachandra.Mallappa@amd.com;
> Hongtao Liu <hongtao.liu@intel.com>
> Subject: Enable the vectorizer at -O2 for GCC 12
> 
> 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?
> 
> Thanks,
> Florian

Re: Enable the vectorizer at -O2 for GCC 12

[Hongtao Liu]

On Wed, Sep 1, 2021 at 7:24 PM Tamar Christina via Gcc <gcc@gcc.gnu.org> wrote:
>
> -- edit, added list back in --
>
> Just to add some AArch64 numbers for Spec2017 we see 2.1% overall Geomean improvements (all from x264 as expected) with no real regressions (everything within variance) and only a 0.06% binary size increase overall (of which x264 grew 0.15%) using the very cheap cost model.
>
> So we'd be quite keen on this as well.
>
> Cheers,
> Tamar
>
> > -----Original Message-----
> > From: Gcc <gcc-bounces+tamar.christina=arm.com@gcc.gnu.org> On Behalf
> > Of Florian Weimer via Gcc
> > Sent: Monday, August 30, 2021 2:05 PM
> > To: gcc@gcc.gnu.org
> > Cc: jakub@redhat.com; Richard Earnshaw <Richard.Earnshaw@arm.com>;
> > Segher Boessenkool <segher@kernel.crashing.org>; Richard Sandiford
> > <Richard.Sandiford@arm.com>; Premachandra.Mallappa@amd.com;
> > Hongtao Liu <hongtao.liu@intel.com>
> > Subject: Enable the vectorizer at -O2 for GCC 12
> >
> > 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?
> >
> > Thanks,
> > Florian
>

A patch is posted at [1] to enable auto-vectorization at O2 w/
very-cheap cost mode.

[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578877.html

-- 
BR,
Hongtao