This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Improving reload inheritance code generation and predictability


On 11/23/10 09:49, Vladimir Makarov wrote:
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.
Yea. It was a nice improvement.

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).
I was rather surprised to find that just scanning the caller-save created insns and relying upon the old DF data for everything else was actually the slowest approach. I'm at a bit of a loss to explain that behavior. I can see the extra level of indirection for each REG appearing in a non-caller-save insn that we peek at in allocate_reload_reg, but I'm having trouble seeing how that is costing so much more than a df_insn_rescan_all.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]