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).
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.
