This is the mail archive of the 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]
Other format: [Raw text]

Re: RFC: Plan for cleaning up the "Addressing Modes" macros

Zack Weinberg <> writes:

> So, the plan: Step 1 introduces - one at a time - target hooks
> corresponding to each of the above macros.  All callers are changed to
> use the hooks.  The default definitions of the hooks invoke the
> existing macros.  The hardest part of this is working out exactly what
> their sole callers expect of LEGITIMIZE_ADDRESS and
> LEGITIMIZE_RELOAD_ADDRESS.  The manual, unfortunately, is not very
> clear.  I think that in both cases it amounts to "either replace X
> with a new value and jump to WIN, or leave X unmodified and drop
> through", which can be translated to "return a new value for X, or
> NULL", but I'm not sure, particularly about LEGITIMIZE_RELOAD_ADDRESS
> and its interaction with push_reload.

I'm replying to a week old message here--I may have missed something
in the interim.

I think this change is a great idea.  I want to point out something
you probably already noticed: some definitions of
LEGITIMIZE_RELOAD_ADDRESS rely on the fact that they appear in
reload.c in the only caller, find_reloads_address.  For example, the
definition in avr.h calls make_memloc, which is a static function in
reload.c.  I thought there was at least one other case, but maybe it
has been fixed.

In general writing LEGITIMIZE_RELOAD_ADDRESS requires a good knowledge
of what reload does and does not do.  It is possible to call
push_reload on some portion of X, not change X, and still jump to WIN.
This would be appropriate if the default reloading of operands isn't
optimal for some reason, but the address can indeed be reloaded.
E.g., alpha_legitimize_reload_address, or the definition in avr.h.
That said, a hook in which returning non-NULL should trigger "goto
win" would be perfectly reasonable.  The troubling case would be one
which modified X and did *not* jump to WIN.  While that is
theoretically possible, it is unnecessary--if you know how to reload
the address, it's a lot simpler to call push_reload yourself than to
construct something which will cause find_reloads_address to make the
right calls.


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