This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: find_mem_givs SMALL_REGISTER_CLASSES patch
- To: John Wehle <john at feith dot com>, rth at cygnus dot com
- Subject: Re: find_mem_givs SMALL_REGISTER_CLASSES patch
- From: Richard Henderson <rth at cygnus dot com>
- Date: Sun, 28 Jun 1998 15:27:34 -0700
- Cc: law at cygnus dot com, egcs-patches at cygnus dot com
- References: <199806281938.PAA24156@jwlab.FEITH.COM>
- Reply-To: Richard Henderson <rth at cygnus dot com>
On Sun, Jun 28, 1998 at 03:38:40PM -0400, John Wehle wrote:
> I only don't record givs which are already a valid address for the machine.
> The potential benefit of recording the giv is less than the potential
> performance loss due to causing register spillage on a register poor
> machine.
Maybe, maybe not. There is also the potental for not combining
address givs with reg givs, requiring twice as many registers.
> egcs-19980621 with find_mem_givs patch: 105
> egcs-19980621 with loop mark 10 patch: 103
>
> Your patch (judging by its relative size :-) looks like it does more
> than my little change.
Indeed.
I had a look at this test on a pII/233, all with today's cvs:
unpatched: 81.62 81.62 81.62
your patchlet: 96.27 95.46 95.46
mark 12a: 96.27 96.27 96.27
There are two things loop could do better
- combine probably related bivs (j = 2*i)
- eliminate bivs whose final value is not constant, but invariant.
The second of these I just noticed today, the first is hard, and
doesn't come up that often in practice, afaik.
What's left in the mix, as far as I can tell, is register allocation
problems. With s/j/i*2/g in place, we use 3 integer regs in the loop
(leaving 3 open, mind) but still manage to put the loop end condition
on the stack. Fixing that up by hand I get
106.26 106.26 105.27
Past that there may be scheduling issues, but I don't know enough
about modern ia32 chips to be able to tell.
r~