Re: base + index register addressing

Re: base + index register addressing

[meissner]

| 
|   In message <199710170919.WAA23619@ongaonga.chch.cri.nz>you write:
|   > 
|   > Here's a patch that I've found that improves register allocation
|   > where the memory address is the sum of two registers.
| Don't forgot those ChangeLog entries!
| 
| I've installed this patch into egcs.

I was going to comment that the patch might be even better, if it dealt with
register + scaled register that some machines have (such as the x86, ns32k, 88k
to name the ones I've dealt with).

Re: base + index register addressing

[Jeffrey A Law]

  In message < 199710171559.LAA25330@tweedledumb.cygnus.com >you write:
  > | 
  > |   In message <199710170919.WAA23619@ongaonga.chch.cri.nz>you write:
  > |   > 
  > |   > Here's a patch that I've found that improves register allocation
  > |   > where the memory address is the sum of two registers.
  > | Don't forgot those ChangeLog entries!
  > | 
  > | I've installed this patch into egcs.
  > 
  > I was going to comment that the patch might be even better, if it
  > dealt with register + scaled register that some machines have (such
  > as the x86, ns32k, 88k to name the ones I've dealt with).
It's worth noting that patch only helps when the base/index is a hard reg,
which limits its usefulness on most of our platforms.  It's unclear if
the benefit for handling scaled register would outweigh the work involved.
jeff

Re: base + index register addressing

[Michael P. Hayes]

Jeffrey A Law writes:
 >   > I was going to comment that the patch might be even better, if it
 >   > dealt with register + scaled register that some machines have (such
 >   > as the x86, ns32k, 88k to name the ones I've dealt with).
 > It's worth noting that patch only helps when the base/index is a hard reg,
 > which limits its usefulness on most of our platforms.  It's unclear if
 > the benefit for handling scaled register would outweigh the work involved.

Most of the utility of the patch occurs when an incoming function
argument is in a hard base (or possibly index) register.   

IMO, things would be simpler if two register addresses were
canonicalized so that the base register preceeded the index register,
i.e., (mem (plus (base_reg) (index_reg)).  This would reduce the
ambiguity when it comes to allocating base and index registers.

mph...

Re: base + index register addressing

[Jeffrey A Law]

  In message < 199710172339.MAA26949@ongaonga.chch.cri.nz >you write:
  > Most of the utility of the patch occurs when an incoming function
  > argument is in a hard base (or possibly index) register.   
Yup.  I'm all too aware of losing base vs index distinctions
when hard argument registers.

You see, on the PA, it's absolutely critical that we be able to
distinguish the base from the index -- if you reverse them in a
memory reference it will fail at runtime.  Furthermore, any
general register can be a base or index.  Thus we can't use a
set of registers to know which is the base and which is the index.

Most of the time we can figure out which is the base by looking
at REGNO_POINTER_FLAG.  However, that can't detect cases where
a pass eliminates a copy from a hard incoming arg register to
a pseudo with REGNO_POINTER_FLAG set.

  > IMO, things would be simpler if two register addresses were
  > canonicalized so that the base register preceeded the index register,
  > i.e., (mem (plus (base_reg) (index_reg)).  This would reduce the
  > ambiguity when it comes to allocating base and index registers.
Yes.  I even proposed this once and Kenner rejected the idea.

jeff

Re: base + index register addressing

[Nick Ing-Simmons]

Jeffrey A Law <law@cygnus.com> writes:
>  In message < 199710172339.MAA26949@ongaonga.chch.cri.nz >you write:
>  > Most of the utility of the patch occurs when an incoming function
>  > argument is in a hard base (or possibly index) register.   
>Yup.  I'm all too aware of losing base vs index distinctions
>when hard argument registers.
>
>You see, on the PA, it's absolutely critical that we be able to
>distinguish the base from the index -- if you reverse them in a
>memory reference it will fail at runtime.  Furthermore, any
>general register can be a base or index.  Thus we can't use a
>set of registers to know which is the base and which is the index.

On some of TI's DSPs  index/base are very important as well.
This is almost the inverse of above case - sets of registers are vital !
Here to use a register as an index its hard-register number has to be 
"related" to the hard register number of the base.
Current GCC register allocation just cannot handle this, so I have
"given up" (and just lurk here).

Re: base + index register addressing

[Joern Rennecke]

> On some of TI's DSPs  index/base are very important as well.
> This is almost the inverse of above case - sets of registers are vital !
> Here to use a register as an index its hard-register number has to be 
> "related" to the hard register number of the base.
> Current GCC register allocation just cannot handle this, so I have
> "given up" (and just lurk here).

Why so you think gcc cannot handle this?  Just describe the relatedness
of the registers with register classes, and enforce it in the REG_OK_STRICT
version of GO_IF_LEGITIMATE_ADDRESS .

Re: base + index register addressing

[Nick Ing-Simmons]

Joern Rennecke <amylaar@cygnus.co.uk> writes:
>> On some of TI's DSPs  index/base are very important as well.
>> This is almost the inverse of above case - sets of registers are vital !
>> Here to use a register as an index its hard-register number has to be 
>> "related" to the hard register number of the base.
>> Current GCC register allocation just cannot handle this, so I have
>> "given up" (and just lurk here).
>
>Why so you think gcc cannot handle this?  Just describe the relatedness
>of the registers with register classes, and enforce it in the REG_OK_STRICT
>version of GO_IF_LEGITIMATE_ADDRESS .

Sure _reload_ can handle it, but allocator does not.  
Practice shows gcc generates reg-reg move on nearly every index operation.

If there is a way round this I may take another look ...

The problem is that 'class for index' and 'class for base' cannot be specified. 
There many/several such classes:

e.g. 
   base is 'a0'..'a4'  - index can be 'x0'..'x4'
   base is 'a5'..'a7' - index can be 'x5'..'x7'

Thus 'x5' can be REG_OK_FOR_INDEX if and only if other register is 'a5'..'a7'.
If other register is a pseudo there seemed to be no way to constrain it to the 'a5'..'a7' class.
Thus in the 'loose' case you need so say it is a legitimate address.
Snag is that then pseudo is allocated who-knows-where and the scrict case had 
to move it to another register.


Likewise (and more common) if base is known, there is no way to constrain a pseudo 'index'
to be allocated from a particular class.

Best code resulted by only using one set of each and wasting 1/2 the available registers.

Re: base + index register addressing

[John Carr]

> Current GCC register allocation just cannot handle this, so I have
> "given up" (and just lurk here).

I ran into a similar (but less important) problem working on the IBM
RT port a long time ago.  The output register of RT shift instructions
can be (source register number) or (source register number XOR 1).
Getting the allocator to know about the second version was impractical.
Kenner's comment was "this is fairly easy to do with register coloring
and hard otherwise."

Reload is easier to change than register allocation but it is less
helpful.  allocate_reload_reg should be simple to fix to know about
register allocation interdependencies (given a choice of registers
call a macro to pick the best for the context), and new_spill_reg and
its callers not too difficult.

Re: base + index register addressing

[Richard Henderson]

On Fri, Oct 17, 1997 at 11:07:12AM -0600, Jeffrey A Law wrote:
> Well, on targets where we do fp/ap elimination we still don't care
> all that much since most don't have reg + scaled reg/const + constant offset.
> Which is what such addresses will turn into when the fp/ap gets eliminated.
> 
> I'm not saying this extension isn't useful, just that it isn't as useful
> as one might initially think.

But i386 and m68k do, which are used widely enough to make it worth it.


r~

Re: base + index register addressing

[Jeffrey A Law]

  In message <199710170919.WAA23619@ongaonga.chch.cri.nz>you write:
  > 
  > Here's a patch that I've found that improves register allocation
  > where the memory address is the sum of two registers.
Don't forgot those ChangeLog entries!

I've installed this patch into egcs.

Thanks,
jeff

Re: base + index register addressing

[Jeffrey A Law]

  In message < 199710171637.MAA26061@tweedledumb.cygnus.com >you write:
  > | It's worth noting that patch only helps when the base/index is a hard reg
  > ,
  > | which limits its usefulness on most of our platforms.  It's unclear if
  > | the benefit for handling scaled register would outweigh the work involved
  > .
  > 
  > Consider when the base register is the stack/frame/argument pointer.
Well, on targets where we do fp/ap elimination we still don't care
all that much since most don't have reg + scaled reg/const + constant offset.
Which is what such addresses will turn into when the fp/ap gets eliminated.

I'm not saying this extension isn't useful, just that it isn't as useful
as one might initially think.

jeff

Re: base + index register addressing

[meissner]

| It's worth noting that patch only helps when the base/index is a hard reg,
| which limits its usefulness on most of our platforms.  It's unclear if
| the benefit for handling scaled register would outweigh the work involved.

Consider when the base register is the stack/frame/argument pointer.