Re: [PATCH V3 1/7] df: Add DF_LIVE_SUBREG problem

[Vladimir Makarov <vmakarov@redhat.com>]

On 11/14/23 12:18, Vladimir Makarov wrote:
>
> On 11/14/23 03:38, Lehua Ding wrote:
>>
>>
>> This is perfectly fine, the code inside the live_subreg problem has a 
>> branch that goes through similar logic to live_reg if it finds no 
>> subreg inside the program. Then when the optimization level is less 
>> than 2, it doesn't track the subreg. By the way, I'd like to ask you 
>> if you have certain programs where RA has a big impact on compilation 
>> time to offer? Or any suggestions about it?
>>
> I've analyzed effect of your patches to -O2 compilation time on 
> compilation of some old version of combine.c.  The total GCC 
> compilation time increased by about 3%. I used x86_64 release mode 
> compiler.  Here are my more detail findings:
>
> RA compile time increased by 43%.
>
> 54% of this increase is due df_analyze time increase and 38% is due to 
> overall ira_color increase (assign_hard_reg execution time increased 
> in 50 times but still such big increase is 1/3 of overall ira_color 
> increase).
>
Sorry, due to different inlining of assign_hard_reg I reported wrong 
numbers for this function (for version w/o patches only assigning on the 
region border was taken), the compilation times for this function is 
basically the same.
> The rest (about 10%) of overall RA increase is mostly LRA increase due 
> to lra_create_live_ranges.
>
> To see where 6% GCC compilation time increase on SPEC2017 is spent 
> would be more interesting but it needs a lot of time for analysis.
>
>