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