[RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro

Roman Zippel zippel@linux-m68k.org
Thu Mar 1 02:43:00 GMT 2007


Hi,

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 
well.

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:

float g1(void);
void f1(float *p, int i)
{       
        p[i] = g1();
}
void g2(float);
void f2(float *p, int i)
{       
        g2(p[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 
itself?
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 
possible:

	move.l	#-0x10000,%d0
	move.l	(%fp,%d0),-(%sp)

or

	move.l	%fp,%a0
	add.l	#-0x10000,%a0
	fmove.s	(%a0),%fp0

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

	move.l  #-0x10000,%d0
	move.l	(%fp,%d0),%d0
	move.l	%d0,(%a1,%d1)

whereas the following is two bytes shorter

	move.l	%fp,%a0
	add.l	#-0x10000,%a0
	move.l	(%a0),(%a1,%d1)

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 
instruction.

bye, Roman



More information about the Gcc-patches mailing list