Re: [PATCH 0/7] ira/lra: Support subreg coalesce

[Lehua Ding <lehua.ding@rivai.ai>]

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.ding@rivai.ai