This is the mail archive of the gcc@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: number of spills and reloads


Hi James,

I'm doing some experiments on Pentium machines, and basically I need 3 kinds 
of statistics after reloading:
1) number of memory stores, eg. [sp+4] <- r1
2) number of memory loads, eg. r1 <- [sp+4]
3) number of combined stores and loads with addressing mode available
on CISC-like architectures: eg. [sp+4] <- [sp+4] + r1, or r1 <- [sp+4]
+ r1
where r1 is the hardware register.

>From your previous email,  I think  the place in which REG is modifed
into MEM is only for case 3)??    Could you please tell me which
functions in the codes does this modification?

>From the greg dump, it seems that the memory stores is related to
RELOAD_FOR_OUTPUT.  Is it possible to obtain (1) from the function
"emit_output_reload_insns"?

For case (2), I don't have much clue.  Is it related to RELOAD_FOR_INPUT? 
For the dump, it seems that for any non-optional RELOAD_FOR_INPUT or
RELOAD_FOR_OPERAND_ADDRESS, a "memory load" will be generated.
Is it correct?

Thanks.

On Mon, 30 Aug 2004 17:14:08 -0700, James E Wilson
<wilson@specifixinc.com> wrote:
> On Wed, 2004-08-25 at 22:45, Qiong Cai wrote:
> > I'm a bit confused with "spill register". Consider the following example,
> > r0 <- [sp+4] + [sp + 8]
> > then operand 1 must be the register. so reload into register r1 first
> > r1 <- [sp+4]
> > Is the register r1 a "spill" register?
> 
> A spill register is an allocatable register that the reload pass can use
> for resolving reloads.  Preferably this is a register that wasn't used
> by the local or global register allocation passes.  But if we need a
> reg, and there isn't one free, we can make one free by picking a hard
> reg, and then for every pseudo reg allocated to that hard reg, we spill
> it to the stack.  Since this is expensive, the reload pass tries to
> compute the minimum number of spill regs needed.
> 
> For your example, yes, in the common case, r1 will be a spill reg.
> However, it isn't guaranteed to be a spill reg.  There is quite a bit of
> complexity in reload to try to avoid using a spill reg when we don't
> need one, so in complicated cases we might be able to reuse a register
> from elsewhere.  For instance, if the previous instruction was
>        [sp+4] <- r1
> then we will use r1 instead of a spill reg.  (Though of course, r1 could
> itself be a spill reg if the previous instruction needed a spill reg.)
> 
> > I need the number of "stores" or "spills" to memory caused by register
> > allocation.
> > It seems that this is close to your second measure.
> 
> There are actually two things here.  There are pseudos which get
> assigned to a hard reg in local/global, and then spilled to the stack in
> reload.  And there are pseudos which never get assigned to a hard reg.
> You may have to count these separately, as they may be handled in
> different places.
> 
> A pseudo may be used in more than one place, which means you have to
> find all of the places where they are used.  Reload doesn't track this
> info because it doesn't need to know.  We modify a REG to a MEM in
> place, so there is no need to know where all of the uses are.  It just
> needs to know that every instruction is fixed.  It doesn't need to know
> how many uses there are of each pseudo.  You might need a separate scan
> over all of the instructions to compute this.
> 
> Then of course you need the dynamic count calculation for every use of a
> pseudo.
> 
> > Where's the place in which the final reload is emitted?  If I know the place,
> > then I just count the number of reload there.
> 
> reload_as_needed.  It calls find_reloads to compute the number of
> reloads needed for each instruction, and then emit_reload_insns to emit
> the instructions needed to perform the reloads.
> 
> 
> --
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
> 
> 


-- 
Qiong Cai
www.cse.unsw.edu.au/~qiongc


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