[Bug tree-optimization/94375] New: 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

[Bug tree-optimization/94375] New: 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375

            Bug ID: 94375
           Summary: 548.exchange2_r run time is 8-18% worse than GCC 9 at
                    -Ofast -march=native
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jamborm at gcc dot gnu.org
            Blocks: 26163
  Target Milestone: ---
              Host: x86_64-linux
            Target: x86_64-linux

When compiled with trunk revision 26b3e568a60 and options -Ofast
-march=native -mtune=native, SPEC 2017 INTrate benchmark
548.exchange2_r runs 19% slower on AMD Zen2 and 12% slower on Intel
Cascade Lake than when built with GCC 9.2.

It appears that the main culprit is the vectorizer, switching it off
recovers the performance - it is in fact even some 4% better than GCC
9 on AMD).

Side note: with --param ipa-cp-eval-threshold=1 --param
ipa-cp-unit-growth=80 one can exchange that is 25% faster yet but that
is a different issue.

This started happening in the autumn but not exactly at one point, as
the following table of run-times relative to GCC 9.2 shows. 

Revision:                  time 
-------------------------  ----
d82f38123b5 (Nov 14 2019)  117%
d9adca6e663 (Nov 5 2019)   117%
bf037872d3c (Oct 24 2019)  101%
77ef339456f (Oct 14 2019)  118%
38a734350fd (Oct 3 2019)   100%
d469a71e5a0 (Sep 23 2019)  101%


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/94375] 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375

--- Comment #1 from Hongtao.liu <crazylht at gmail dot com> ---
Try -mprefer-vector-width=128,256-bit vectorization is not helpful for 548
according to our experience.

[Bug tree-optimization/94375] 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |53947

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Do we ever hit the vectorized paths?  I guess the number of iterations isn't
bound so the cost model has a hard time, possibly only triggering at runtime.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/94375] 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375

--- Comment #3 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Hongtao.liu from comment #1)
> Try -mprefer-vector-width=128,256-bit vectorization is not helpful for 548
> according to our experience.

I have seen this helping on one system running SLES 15.1 and with
trunk abe13e1847f (Feb 17 2020) but not on another running openSUSE
Tumbleweed and with trunk revision 26b3e568a60 (Mar 23 2020).  So,
from my perspective, perhaps it helps, perhaps it doesn't.

[Bug tree-optimization/94375] 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375

--- Comment #4 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Martin Jambor from comment #3)
> (In reply to Hongtao.liu from comment #1)
> > Try -mprefer-vector-width=128,256-bit vectorization is not helpful for 548
> > according to our experience.
> 
> I have seen this helping on one system running SLES 15.1 and with
> trunk abe13e1847f (Feb 17 2020) but not on another running openSUSE
> Tumbleweed and with trunk revision 26b3e568a60 (Mar 23 2020).  So,
> from my perspective, perhaps it helps, perhaps it doesn't.

What's your GCC option for OPENSUSE?

Default value of -mprefer-vector-width for -mtune=zenver1 is 128, if that, it
won't help.
Different processor have different tune which may has different default vector
width.

[Bug tree-optimization/94375] 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375

--- Comment #5 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Hongtao.liu from comment #4)
> (In reply to Martin Jambor from comment #3)
> > (In reply to Hongtao.liu from comment #1)
> > > Try -mprefer-vector-width=128,256-bit vectorization is not helpful for 548
> > > according to our experience.
> > 
> > I have seen this helping on one system running SLES 15.1 and with
> > trunk abe13e1847f (Feb 17 2020) but not on another running openSUSE
> > Tumbleweed and with trunk revision 26b3e568a60 (Mar 23 2020).  So,
> > from my perspective, perhaps it helps, perhaps it doesn't.
> 
> What's your GCC option for OPENSUSE?
> 
> Default value of -mprefer-vector-width for -mtune=zenver1 is 128, if that,
> it won't help.
> Different processor have different tune which may has different default
> vector width.

for -march=native, it depends on processor of your server/client.

[Bug tree-optimization/94375] 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375

--- Comment #6 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> Do we ever hit the vectorized paths?

What's the best way to find out?  If I open the disassembled code in
perf report and search for ymm, some of these (groups of) instructions
have (very few) samples, but more often they don't.

[Bug tree-optimization/94375] 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Martin Jambor <jamborm at gcc dot gnu.org> ---
Thu bug as specified here has been fixed by commits 31584824665, 91153e0af9a,
67ce9099bc9, 1e7fdc02cba, 7d2cb2755a1.

We can still do better on the benchmark if we fix PR 98782.