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

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

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