Re: find_reloads_address_1 question

[Ulrich Weigand <weigand@immd1.informatik.uni-erlangen.de>]

Joern Rennecke wrote:

> > Specifically I've tried to declare addresses of the form
> >  (plus (plus (reg) (const_int)) (plus (reg) (const_int)))
> ...
> > But this caused bootstrap failure because reload simply
> > didn't reload the registers to hard registers and left
> > pseudos in ...
> > 
> > Am I just trying something stupid here, or would this be
> > considered a bug in reload?
> 
> Yes.  Both.  You are allowing non-canonical RTL, and AFAICT there is
> no good reason to do this here. 

Well, I tried this change because a pattern of the type above
was generated by combine through substing into an address.  The
combine attempt then failed because the address didn't pass the
LEGITIMATE_ADDRESS test, and so I thought it was my fault for not
accepting everything that can in fact be translated to a correct
address.

However, if there is a canonical form for addresses that reload
depends upon (across all architectures), then I guess combine
would be at fault here for not properly canonifying addresses
after substing into them ...  I'll reexamine my test case and
try to find out what's going on here.

> On the other hand, gcc would be easier
> to port if find_reloads_address either had a fallback method to reload
> all kinds of addressing modes, or at least aborted for ones that it
> doesn't handle.  Note that there is a comment at the start of this function
> that hints at this defect:  ...this is not fully machine-customizable;... .

After a closer look at find_reloads_address_1 I guess I understand
why it doesn't simply recurse over subexpressions: it tries to 
decide which operand of the PLUS to use as base and which as index
for those architectures where the sets of possible base and index
registers are not equal.  Do to so you basically have to analyse
both operands of the PLUS ... (This is not the case on our architecture,
which is probably why I overlooked this problem.)

But I certainly agree that aborting in this case would be preferable
to just leaving an incorrect address in.

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de