Re: Improving reload inheritance code generation and predictability

[Jeff Law <law at redhat dot com>]

On 11/19/10 10:25, Vladimir Makarov wrote:
> 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).
So I've done a little more work on this.   The big surprise is a 
df_finish call can be quite expensive and given that IRA already takes 
care of it, the new call in reload1.c was totally unnecessary.  With 
that fix and removal of an unnecessary mapping from hard reg back to an 
index into SPILL_REGS, this code very close to compile-time neutral.

I had a version which only df-scanned blocks which were going to be 
insn-scanned which helped a little more, I didn't feel it was worth 
leaving DF info in a half-updated half-not-updated state.


Average times over 5 runs of compiling a big blob of .i files I have 
lying around:

Baseline (unpatched):                             705.57
Lazily DF scan the entire function:          706.66

So we're at about .15% compile-time increase -- which is IMHO reasonable.

I've also added a PARAM to clamp the number of insns we scan.  Clamping 
at 20 insns gets the vast majority of cases we care about.

Jeff