[RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
Thu Mar 1 02:43:00 GMT 2007
On Tue, 27 Feb 2007, Jeffrey Law wrote:
> So after poking at this for a few minutes with the debugger, I'm really
> interested in why you think fixing double_reg_address_ok to be indexed
> by the mode of the memory reference is insufficient to fix this problem.
I don't want to judge which patch is better, but I still don't understand
what's so wrong with Richard's approach. What you basically seem to say is
that MODE_BASE_REG_CLASS is ok, because we can't that easily work around
it in the generic code.
Your patch is not that different - it adds a mode argument to the index
register (it just differs how it's done), something you were quite opposed
to previously. Additionally your patch only addresses a specific case,
which opens the question, whether it might be needed in other places as
Actually some of your arguments can be used equally against your patch.
Specifically that integer register can hold fp values and vice versa.
Let's assume we want to allow an index in some modes, e.g. for
memory-memory moves or where we know it's an integer register (e.g. the
previous function return value in %d0), thus in examples like this we can
determine quite early whether the indexed mode is beneficial:
void f1(float *p, int i)
p[i] = g1();
void f2(float *p, int i)
This means G_I_L_A would become more permissive and your change becomes
unnecessary (all double_reg_address_ok values are true), but it also means
reload would be able to solve the stack register problem by using an
integer register as reload register. At this point it would also become
permissive to LEGITIMIZE_RELOAD_ADDRESS to generate a better reload and
IMO this makes the usage restrictions on LEGITIMIZE_RELOAD_ADDRESS
hair-splitting - yes, it was initially meant as optimization, but what
evil does it do to also use it to fix addresses generated by reload
Anyway, while I like this idea to allow a few more addressing modes if
possible, I think it's more a long term option, as it requires many
predicate adjustments in m68k.md.
I would also like to mention another possible option I brought up earlier.
Since reloads for memory operands are done quite early, it's almost
impossible to produce the most efficient reload, as it depends on the
selected instruction which addressing mode can be used, e.g. in our fp
stack value example the following instruction sequences are theoretically
As seen in the last example the tendency of reload to prefer the indexed
mode is not always beneficial and to make things a little more complex -
the index mode on ColdFire is actually even more restricted as it can only
be used once per instruction, so for an example like this:
(set (mem (plus (reg %a1) (reg %d1)))
(mem (plus (reg %fp) (const_int -0x10000)))
reload currently generates something like this
whereas the following is two bytes shorter
So in order to improve the reload handling for this, we could use the
constraints of the instruction, but this means we need to delay the reload
of memory operands (or at least part of it) in find_reloads(), which looks
doable, but someone more familiar needs to comment on this.
OTOH this could also cleanup all the current base/register handling based
on the mode and give us more flexibility, as it can be controlled per
More information about the Gcc-patches