On 2022-05-29 23:05, Hongtao Liu wrote:
On Fri, May 27, 2022 at 5:12 AM Vladimir Makarov via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
On 2022-05-24 23:39, liuhongt wrote:
Rigt now, mem_cost for separate mem alternative is 1 * frequency which
is pretty small and caused the unnecessary SSE spill in the PR, I've tried
to rework backend cost model, but RA still not happy with that(regress
somewhere else). I think the root cause of this is cost for separate 'm'
alternative cost is too small, especially considering that the mov cost
of gpr are 2(default for REGISTER_MOVE_COST). So this patch increase mem_cost
to 2*frequency, also increase 1 for reg_class cost when m alternative.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
Thank you for addressing this problem. And sorry I can not approve this
patch at least w/o your additional work on benchmarking this change.
This code is very old. It is coming from older RA (former file
regclass.c) and existed practically since GCC day 1. People tried many
times to improve this code. The code also affects many targets.
Yes, that's why I increased it as low as possible, so it won't regress
#c6 in the PR.
I can approve this patch if you show that there is no regression at
least on x86-64 on some credible benchmark, e.g. SPEC2006 or SPEC2017.
I've tested the patch for SPEC2017 with both -march=cascadelake
-Ofast -flto and -O2 -mtune=generic.
No obvious regression is observed, the binaries are all different from
before, so I looked at 2 of them, the difference mainly comes from
different choices of registers(xmm13 -> xmm12).
Ok for trunk then?
OK.
Thank you for checking SPEC2017.
I hope it will not create troubles for other targets.
