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
