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

2023-06-20 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858

Kewen Lin  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  ---
Already fixed by Hongtao's fix.

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

2023-05-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858

--- Comment #11 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r14-1252-g4fb66b2329319e9b47e89200d613b6f741a114fc
Author: liuhongt 
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

2023-05-17 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858

--- Comment #10 from Segher Boessenkool  ---
(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

2023-05-16 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858

--- Comment #9 from Kewen Lin  ---
(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

2023-05-16 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858

--- Comment #8 from Hongtao.liu  ---
(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

2023-05-16 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858

--- Comment #7 from Segher Boessenkool  ---
> 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

2023-05-15 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858

--- Comment #6 from Kewen Lin  ---
(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

2023-05-15 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858

--- Comment #5 from Hongtao.liu  ---
(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

2023-05-15 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858

--- Comment #4 from Hongtao.liu  ---
Created attachment 55091
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55091=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

2023-05-15 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858

--- Comment #3 from Kewen Lin  ---
(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

2023-05-15 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858

--- Comment #2 from Hongtao.liu  ---
Does https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617431.html help?