Backend port: Minimizing register usage in favor of memory accesses

Backend port: Minimizing register usage in favor of memory accesses

[xyzzy]

I understand that one of the goals of any optimizing compiler is to maximize 
use of registers since this is the fastest and least space consuming type of 
instruction on most processors.

Thus, C code like:

extern void bar();
int a,b;
foo()
{
	a = 5;
	if ( b > a )
		bar();
}

... produces pseudo-code like:
.word a,b
	move 5,tmp1reg
	move tmp1reg,a

	move b,tmp2reg
	cmp tmp2reg,tmp1reg
	bgt label1
	call bar
label1:
	ret

What I want to do is reverse this and minimize register usage as much as 
possible, massively favoring memory accesses unless a register absolutely 
MUST be used.  Thus, I want my backend to produce code like this:

.word a,b
	move 5,a
	cmp b,a
	bgt label1
	call bar
label1:
	ret

Is there any way to force the GCC backend to do this, if at all?  Will 
defining SMALL_REGISTER_CLASSES to 1 do the trick or is there any other magic 
that can be invoked?  Doing it in the optimizer stage is OK, too... if O2 or 
less.

Many thanks for any help on this.

Re: Backend port: Minimizing register usage in favor of memory accesses

[Joern Rennecke]

> What I want to do is reverse this and minimize register usage as much as 
> possible, massively favoring memory accesses unless a register absolutely 
> MUST be used.  Thus, I want my backend to produce code like this:

Try lowering MEMORY_MOVE_COST.

Re: Backend port: Minimizing register usage in favor of memory accesses

[Jim Wilson]

xyzzy@hotpop.com wrote:
> I understand that one of the goals of any optimizing compiler is to maximize 
> use of registers since this is the fastest and least space consuming type of 
> instruction on most processors.

The goal of an optimizing compiler is to produce the fastest code for 
the target.  If the target wants registers to be used, then we use 
registers.  If the target doesn't want registers to be used, then we 
don't use registers.

> Is there any way to force the GCC backend to do this, if at all?

We have been doing this since the beginning for an i386 target.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Backend port: Minimizing register usage in favor of memory accesses

[xyzzy]

On Tuesday 30 March 2004 22:31, Jim Wilson wrote:
> xyzzy@hotpop.com wrote:
> > I understand that one of the goals of any optimizing compiler is to
> > maximize use of registers since this is the fastest and least space
> > consuming type of instruction on most processors.
>
> The goal of an optimizing compiler is to produce the fastest code for
> the target.  If the target wants registers to be used, then we use
> registers.  If the target doesn't want registers to be used, then we
> don't use registers.
>
> > Is there any way to force the GCC backend to do this, if at all?
>
> We have been doing this since the beginning for an i386 target.

Jim, thanks for the reply... Also, thanks to Joem.

Can you point me in the right place to look in the i386 target so I don't mess 
this up?  Is what Joem said about "lowering MEMORY_MOVE_COST" the only thing 
to do? Is there other black magic involved?

Thanks again.

Re: Backend port: Minimizing register usage in favor of memory accesses

[Richard Earnshaw]

> The goal of an optimizing compiler is to produce the fastest code for 
> the target.

Not necessarily.  The goal of an optimizing compiler is to minimize some 
cost metric.  Sometimes that cost metric is the same as 'target execution 
time' at other times it is something else, such as 'code size'.  Many of 
the specific optimizations performed will be same regardless of the 
overall cost metric being worked on; but not always.

R.

Re: Backend port: Minimizing register usage in favor of memory accesses

[xyzzy]

On Wednesday 31 March 2004 11:43, Richard Earnshaw wrote:
> > The goal of an optimizing compiler is to produce the fastest code for
> > the target.
>
> Not necessarily.  The goal of an optimizing compiler is to minimize some
> cost metric.  Sometimes that cost metric is the same as 'target execution
> time' at other times it is something else, such as 'code size'.  Many of
> the specific optimizations performed will be same regardless of the
> overall cost metric being worked on; but not always.
>
> R.
Yes, my mistake... I meant to say "the BEST code for the target", which is 
horribly subjective.

Re: Backend port: Minimizing register usage in favor of memory accesses

[Robert Dewar]

Richard Earnshaw wrote:

> Not necessarily.  The goal of an optimizing compiler is to minimize some 
> cost metric.  Sometimes that cost metric is the same as 'target execution 
> time' at other times it is something else, such as 'code size'

Or data size. In some embedded environments, data size and code size
are radically different metrics. The latter may be in ROM and quite
large, the former may be very limited RAM.

While minimizing code space is often closely related to minimizing
execution time of code, minimizing data space is actually sometimes 
quite at odds with minimizing time.

For interesting details on some optimizations
for reducing space, see Janet Fabri's thesis on Automatic
Storage Optimization, NYU, R. Dewar advisor, 1982 (also published as
Fabri, Janet. Automatic Storage Optimization. UMI Research Press, 1982.)
Unfortunately this thesis does not seem to be online anywhere that
I can find. One day it would be nice if all University Microfilms
material made it onto the web!

Re: Backend port: Minimizing register usage in favor of memory accesses

[Jim Wilson]

xyzzy@hotpop.com wrote:
> Can you point me in the right place to look in the i386 target so I don't mess 
> this up?  Is what Joem said about "lowering MEMORY_MOVE_COST" the only thing 
> to do? Is there other black magic involved?

If your target has patterns that allow MEMs, then gcc will use them. 
Since some gcc optimizations (like combine) try to reduce the total 
number of instructions, you will naturally get code that uses MEM in 
preference to REG.

You shouldn't really need to do anything else to get started.  There are 
other things that you can do to fine tune the result and address 
specific problems, such as setting MEMORY_MOVE_COST.  However, since you 
haven't reported any specific problems, I can't offer any specific 
suggestions.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com