This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: base + index register addressing


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]