Re: find_reloads_address_1 question

[Joern Rennecke <amylaar at onetel dot net dot uk>]

> This means that on the first call of find_reloads, the address
> is changed to 
>    (plus (plus (reg 11) (const_int 124)) (reg 0))
> which is non-canonical.

This is done assuming that the inner plus is going to be loaded into
a reload register. 
It would be interesting to find out why this has not happened.
Of course, even when this can be fixed, this leaves the issue of the extra
reload.

> Is there something in the backend I can do to fix this?
> (E.g. accept non-canonical addresses in print_operand,
> or allow register 0 in REG_OK_FOR_INDEX_P in the non-strict
> case ...)  Or should reload behave differently here?

I think changing REG_OK_FOR_INDEX_P would be preferable if you want to work
around this problem in your backend.  You can check reload_in_progress to
avoid an impact on the register (class) preferences in the pre-reload phases.

Alternatively, when you have fixed the problem of not reloading the
inner plus, you can use LEGITIMZE_RELOAD_ADDRESS to tackle the
optimization issue.

A fix in reload at the point that you identified could be to replace the
index by a pseudo of the same mode before trying checking
memory_address_p.  In general, the index might be something that is not
a REG, e.g. a MEM, but then it would make even more sense to use a pseudo
to consider reloading the entire index into a suitable register.
There are two places in find_reloads_address where such a change would have
to be made, so it would make sense to have a helper function to do the
check including modifying and restoring the address.