Hi Vladimir,
While you're starting your review, please review v3 version that fixes
some ICE issues, thanks.
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636178.html
On 2023/11/12 20:01, Lehua Ding wrote:
Hi Vladimir,
On 2023/11/10 4:24, Vladimir Makarov wrote:
On 11/7/23 22:47, Lehua Ding wrote:
Lehua Ding (7):
ira: Refactor the handling of register conflicts to make it more
general
ira: Add live_subreg problem and apply to ira pass
ira: Support subreg live range track
ira: Support subreg copy
ira: Add all nregs >= 2 pseudos to tracke subreg list
lra: Apply live_subreg df_problem to lra pass
lra: Support subreg live range track and conflict detect
Thank you very much for addressing subreg RA. It is a big work. I
wanted to address this long time ago but have no time to do this by
myself.
I tried to evaluate your patches on x86-64 (i7-9700k) release mode
GCC. I used -O3 for SPEC2017 compilation.
Here are the results:
baseline baseline(+patches)
specint2017: 8.51 vs 8.58 (+0.8%)
specfp2017: 21.1 vs 21.1 (+0%)
compile time: 2426.41s vs 2580.58s (+6.4%)
Spec2017 average code size change: -0.07%
Improving specint by 0.8% is impressive for me.
Unfortunately, it is achieved by decreasing compilation speed by 6.4%
(although on smaller benchmark I saw only 3% slowdown). I don't know
how but we should mitigate this speed degradation. May be we can find
a hot spot in the new code (but I think it is not a linear search
pointed by Richard Biener as the object vectors most probably contain
1-2 elements) and this code spot can be improved, or we could use this
only for -O3/fast, or the code can be function or target dependent.
I also find GCC consumes more memory with the patches. May be it can
be improved too (although I am not sure about this).
Thanks for the specint performance data. I'll do my best to get the
compile time and memory issues fixed. I'm very curious to know if the
way used to solve the subreg coalesce problem makes sense to you?
I'll start to review the patches on the next week. I don't expect
that I'll find something serious to reject the patches but again we
should work on mitigation of the compilation speed problem. We can
fill a new PR for this and resolve the problem during the release cycle.
--
Best,
Lehua (RiVAI)
lehua.d...@rivai.ai
