This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: New register allocator branch created
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Subject: Re: New register allocator branch created
- From: Daniel Berlin <dberlin at redhat dot com>
- Date: Sun, 28 Jan 2001 12:36:18 -0500 (EST)
- cc: <dberlin at redhat dot com>, <gcc at gcc dot gnu dot org>
On Sun, 28 Jan 2001, Richard Kenner wrote:
> For instance, for cp-demangle.c, the older allocator does this on
> demangle_special name:
>
> This had 54 spills.
>
> The new one does this:
> \
> It has 90 spills.
>
> So I'm not sure what you are showing.
err, your numbers are wrong.
Those 90 spills aren't real spills, they are scratches/symbol_refs being
filled in by reload.
Reloads for insn # 39
Reload 0: reload_out (SI) = (scratch:SI)
LINK_REGS, RELOAD_FOR_OUTPUT (opnum = 4)
reload_out_reg: (scratch:SI)
reload_reg_rtx: (reg:SI 65 lr)
Like that.
The 54 spills are real spills.
If reload finds a reg, it hasn't really spilled.
So when it says "Spilling reg 65", it really spilled.
>
> Would it make you feel better if i just said it performs " a ton" better
> or some other vague, not applicable at all term?
>
> It would actually be good if you could quantify the performance improvement.
> You could compare the static number of memory spills/fills, the number or
> register-register copies, or performance of test cases, perhaps even SPEC.
Don't have time right now.
But when i do, I will.
--Dan