[Bug rtl-optimization/109858] New: r14-172 caused some SPEC2017 bmk to degrade on Power

[Bug rtl-optimization/109858] New: r14-172 caused some SPEC2017 bmk to degrade on Power

[linkw at gcc dot gnu.org]

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

            Bug ID: 109858
           Summary: r14-172 caused some SPEC2017 bmk to degrade on Power
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: linkw at gcc dot gnu.org
  Target Milestone: ---

On Power9, 
  - at option -Ofast, 557.xz_r degraded -1.06%.
  - at option -Ofast, 511.povray_r degraded -1.24%.

On Power10,
  - at option -O2, 520.omnetpp_r degraded -1.84%.

I tried to run them in a few times, the gaps are stable. I've excluded those
one in +-1% as noises. The full data is listed below:

P9 O2:
500.perlbench_r 0.00%
502.gcc_r       -0.20%
505.mcf_r       0.00%
520.omnetpp_r   -0.30%
523.xalancbmk_r 0.00%
525.x264_r      0.00%
531.deepsjeng_r 0.00%
541.leela_r     0.00%
548.exchange2_r 0.00%
557.xz_r        0.00%
503.bwaves_r    0.00%
507.cactuBSSN_r 0.00%
508.namd_r      -0.32%
510.parest_r    0.00%
511.povray_r    0.32%
519.lbm_r       -0.16%
521.wrf_r       0.00%
526.blender_r   0.27%
527.cam4_r      0.00%
538.imagick_r   0.00%
544.nab_r       0.00%
549.fotonik3d_r 0.00%
554.roms_r      0.00%

P9 Ofast:
500.perlbench_r 0.00%
502.gcc_r       0.00%
505.mcf_r       0.00%
520.omnetpp_r   0.00%
523.xalancbmk_r 0.00%
525.x264_r      0.17%
531.deepsjeng_r 0.00%
541.leela_r     0.00%
548.exchange2_r 2.15%
557.xz_r        -1.06%
503.bwaves_r    2.21%
507.cactuBSSN_r -0.20%
508.namd_r      -0.33%
510.parest_r    0.00%
511.povray_r    -1.24%
519.lbm_r       0.00%
521.wrf_r       0.19%
526.blender_r   0.00%
527.cam4_r      0.28%
538.imagick_r   0.32%
544.nab_r       0.00%
549.fotonik3d_r -0.83%
554.roms_r      1.33%

Power10 O2:
500.perlbench_r 0.00%
502.gcc_r       0.33%
505.mcf_r       0.55%
520.omnetpp_r   -1.84%
523.xalancbmk_r 0.00%
525.x264_r      0.36%
531.deepsjeng_r 0.00%
541.leela_r     0.00%
548.exchange2_r 0.00%
557.xz_r        0.31%
503.bwaves_r    0.00%
507.cactuBSSN_r -0.31%
508.namd_r      -0.22%
510.parest_r    -0.64%
511.povray_r    -0.86%
519.lbm_r       -0.75%
521.wrf_r       0.20%
526.blender_r   0.20%
527.cam4_r      0.00%
538.imagick_r   -0.15%
544.nab_r       -0.18%
549.fotonik3d_r 0.00%
554.roms_r      0.00%

Power10 Ofast:
502.gcc_r       0.16%
505.mcf_r       0.00%
520.omnetpp_r   0.00%
523.xalancbmk_r 0.22%
525.x264_r      0.30%
531.deepsjeng_r 0.00%
541.leela_r     0.00%
548.exchange2_r 0.00%
557.xz_r        0.31%

503.bwaves_r    -0.18%
507.cactuBSSN_r 0.00%
508.namd_r      0.22%
510.parest_r    -0.52%
511.povray_r    0.00%
519.lbm_r       0.50%
521.wrf_r       0.00%
526.blender_r   -0.80%
527.cam4_r      0.18%
538.imagick_r   -0.11%
544.nab_r       0.17%
549.fotonik3d_r 0.63%
554.roms_r      -0.63%

[Bug rtl-optimization/109858] r14-172 caused some SPEC2017 bmk to degrade on Power

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
   Target Milestone|---                         |14.0
                 CC|                            |pinskia at gcc dot gnu.org

[Bug rtl-optimization/109858] r14-172 caused some SPEC2017 bmk to degrade on Power

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=109610

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Maybe once PR 109610 is fixed this also is fixed.

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

[crazylht at gmail dot com]

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

--- Comment #2 from Hongtao.liu <crazylht at gmail dot com> ---
Does https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617431.html help?

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

[linkw at gcc dot gnu.org]

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

--- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Hongtao.liu from comment #2)
> Does https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617431.html help?

Sorry, I just measured those degraded bmks with this fix, the results showed it
didn't help.

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

[crazylht at gmail dot com]

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

--- Comment #4 from Hongtao.liu <crazylht at gmail dot com> ---
Created attachment 55091
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55091&action=edit
Only use NO_REGS in cost calculation when !hard_regno_mode_ok for GENERAL_REGS
and mode.

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

[crazylht at gmail dot com]

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

--- Comment #5 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Kewen Lin from comment #3)
> (In reply to Hongtao.liu from comment #2)
> > Does https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617431.html help?
> 
> Sorry, I just measured those degraded bmks with this fix, the results showed
> it didn't help.

Sorry for the inconvience, could you try again with attached patch.
The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and
GENERAL_REGS(which is the case in PR109610), hope it can also fix this
regression.

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

[linkw at gcc dot gnu.org]

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

--- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Hongtao.liu from comment #5)
> (In reply to Kewen Lin from comment #3)
> > (In reply to Hongtao.liu from comment #2)
> > > Does https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617431.html help?
> > 
> > Sorry, I just measured those degraded bmks with this fix, the results showed
> > it didn't help.
> 
> Sorry for the inconvience, could you try again with attached patch.
> The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and
> GENERAL_REGS(which is the case in PR109610), hope it can also fix this
> regression.

Thanks for the prompt fix, I'll do the perf evaluation once the perf boxes get
released (they are used by others now) and get back to you.

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool <segher at gcc dot gnu.org> ---
> The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and
> GENERAL_REGS(which is the case in PR109610), hope it can also fix this
> regression.

That sounds more reasonable.  But, why use any heuristics like this?  Can't you
just look at the actual costs of using mem and regs?

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

[crazylht at gmail dot com]

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

--- Comment #8 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Segher Boessenkool from comment #7)
> > The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and
> > GENERAL_REGS(which is the case in PR109610), hope it can also fix this
> > regression.
> 
> That sounds more reasonable.  But, why use any heuristics like this?  Can't
> you
> just look at the actual costs of using mem and regs?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610#c2

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

[linkw at gcc dot gnu.org]

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

--- Comment #9 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #6)
> (In reply to Hongtao.liu from comment #5)
> > (In reply to Kewen Lin from comment #3)
> > > (In reply to Hongtao.liu from comment #2)
> > > > Does https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617431.html help?
> > > 
> > > Sorry, I just measured those degraded bmks with this fix, the results showed
> > > it didn't help.
> > 
> > Sorry for the inconvience, could you try again with attached patch.
> > The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and
> > GENERAL_REGS(which is the case in PR109610), hope it can also fix this
> > regression.
> 
> Thanks for the prompt fix, I'll do the perf evaluation once the perf boxes
> get released (they are used by others now) and get back to you.

I re-evaluated all SPEC2017 bmks on Power9 and Power10 with this patch (r14-171
vs. r14-172 + this fix), and confirmed it does fix all three degradation found
before and it doesn't cause any new degradation (btw, all the >1% improvements
are gone as well, all the results are neutral).

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Hongtao.liu from comment #8)
> (In reply to Segher Boessenkool from comment #7)
> > > The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and
> > > GENERAL_REGS(which is the case in PR109610), hope it can also fix this
> > > regression.
> > 
> > That sounds more reasonable.  But, why use any heuristics like this?  Can't
> > you
> > just look at the actual costs of using mem and regs?
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610#c2

That is not an answer to my question at all?

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by hongtao Liu <liuhongt@gcc.gnu.org>:

https://gcc.gnu.org/g:4fb66b2329319e9b47e89200d613b6f741a114fc

commit r14-1252-g4fb66b2329319e9b47e89200d613b6f741a114fc
Author: liuhongt <hongtao.liu@intel.com>
Date:   Tue May 16 10:36:16 2023 +0800

    Only use NO_REGS in cost calculation when !hard_regno_mode_ok for
GENERAL_REGS and mode.

    r14-172-g0368d169492017 replaces GENERAL_REGS with NO_REGS in cost
    calculation when the preferred register class are not known yet.
    It regressed powerpc PR109610 and PR109858, it looks too aggressive to use
    NO_REGS when mode can be allocated with GENERAL_REGS.
    The patch takes a step back, still use GENERAL_REGS when
    hard_regno_mode_ok for mode and GENERAL_REGS, otherwise uses NO_REGS.

    gcc/ChangeLog:

            PR target/109610
            PR target/109858
            * ira-costs.cc (scan_one_insn): Only use NO_REGS in cost
            calculation when !hard_regno_mode_ok for GENERAL_REGS and
            mode, otherwise still use GENERAL_REGS.

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassigned at gcc dot gnu.org      |crazylht at gmail dot com

--- Comment #12 from Kewen Lin <linkw at gcc dot gnu.org> ---
Already fixed by Hongtao's fix.