This is the mail archive of the
mailing list for the GCC project.
Re: number of spills and reloads
- From: Qiong Cai <qiong dot cai at gmail dot com>
- To: James E Wilson <wilson at specifixinc dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 1 Sep 2004 17:53:24 +1000
- Subject: Re: number of spills and reloads
- References: <email@example.com> <412D1F08.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
- Reply-to: Qiong Cai <qiong dot cai at gmail dot com>
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]
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
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?
On Mon, 30 Aug 2004 17:14:08 -0700, James E Wilson
> 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
> > 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