Improving reload inheritance code generation and predictability

Vladimir Makarov vmakarov@redhat.com
Tue Nov 23 18:18:00 GMT 2010


  On 11/23/2010 11:37 AM, Jeff Law wrote:
> On 11/19/10 10:25, Vladimir Makarov wrote:
>>
>> That is not about memory increase.  It is about DF data expelling rtl 
>> data from caches.
>>
>> I've just did some measurements of compilation time on your patch on 
>> all_cp2k_gfortran.f90 (> 400K lines of fortran)
>>
>> without patch                                     219.20user
>> with only df calls in reload (see patch below)    221.39user
>> with all your patch                               221.17user
>>
>> So 1% of degradation is only because the patch touches DF-data (not 
>> scanning insns in finding reload reg as someone can think).  Better 
>> inheritance might improve compilation time because less insns are 
>> generated (although it is hard to say the difference on two last 
>> lines is too small).
> Switching to df_insn_rescan_all cuts the cost by about 50%.
Great.  Personally for me 0.5% compilation time increase is already ok, 
especially when you improve the code size.
>    I may be able to only scan the insns created by caller-save and 
> deal with the psuedo->hard reg conversion within mark_spill_regs.  
> I'll be testing that shortly.   Then I'll be looking at Bernd's 
> suggestions (which are a rather different approach to the problem).
Ok.  May be it will be interesting for you, but call insns in 
df-infrastructure are particularly memory hungry (about 40 definitions 
for the insn on x86_64).



More information about the Gcc-patches mailing list