Bad offset to struct member in generated code

Bad offset to struct member in generated code

[Paul Zimmerman]

Hi,

I have a problem while porting gcc to a custom processor. Here is a
simplified example:

struct big_struct {
	...
	int a;
	char b;
	char c;
	...
} testme;

char char_tmp;
int int_tmp;

int testit(void)
{
	char_tmp = testme.c;
	int_tmp = testme.a;
}

For the first line of code in testit(), gcc will load the address of
'testme.c' into a register, then do an indirect 8-bit load with an
offset of 0 to fetch the value of 'testme.c'. This is fine.

For the second line, gcc will reuse the same address register, and
generate an indirect 32-bit load with an offset of -5 to fetch the
value of 'testme.a'. But on our custom processor, the offsets of
indirect load instructions are scaled by the size of the data item.
So the assembly instruction generated for the second line is something
like "ld32 %r1, %r0, -5/4", which can not be translated by the
assembler.

So when accessing a data structure, we need gcc to always use a base
address that is a multiple of 4, to prevent this from happening.

So how do I tell gcc about this limitation of our architecture? Do I do
this somehow using the REG_MODE_OK_FOR_BASE_P or
GO_IF_MODE_DEPENDENT_ADDRESS macros in our architecture's .h file? I am
using the gcc 4.0.2 sources if that matters.

Thanks,
Paul
paulz at synopsys dot com

Re: Bad offset to struct member in generated code

[Ian Lance Taylor]

"Paul Zimmerman" <Paul.Zimmerman@synopsys.com> writes:

> For the second line, gcc will reuse the same address register, and
> generate an indirect 32-bit load with an offset of -5 to fetch the
> value of 'testme.a'. But on our custom processor, the offsets of
> indirect load instructions are scaled by the size of the data item.
> So the assembly instruction generated for the second line is something
> like "ld32 %r1, %r0, -5/4", which can not be translated by the
> assembler.
> 
> So when accessing a data structure, we need gcc to always use a base
> address that is a multiple of 4, to prevent this from happening.
> 
> So how do I tell gcc about this limitation of our architecture? Do I do
> this somehow using the REG_MODE_OK_FOR_BASE_P or
> GO_IF_MODE_DEPENDENT_ADDRESS macros in our architecture's .h file? I am
> using the gcc 4.0.2 sources if that matters.

You need to fix this in GO_IF_LEGITIMATE_ADDRESS.  It may help to look
at thumb1_legitimate_address_p and thumb_legitimate_offset_p in
config/arm/arm.c.

Ian