RE: [ECOS] code optimizations

["Dan Conti" <danc at iobjects dot com>]

> -----Original Message-----
> From: Mark Salter [mailto:msalter@redhat.com]
> Subject: Re: [ECOS] code optimizations
>
> Why is there an extra load? I would think that using compile time
> constants would allow for more optimizations than link time fixups.
> Assume mips like architecture, you either have something like:
> 
>    ori r2, r0, 0xabc
>    lui r1, %hi(foo)
>    sw  r2, %lo(foo)(r1)
> 
> or
> 
>    ori r2, r0, 0xabc
>    lui r1, 0x7ffe
>    sw  r2, 0x1110(r1)

I know i should finish my coffee before i touch email in the morning.

Yes you are correct. I was thinking of two different situations at once
and got confused :)

> Both are equal in size and running time. Better optimization is
> possible with constants if you do a series of stores to different
> addresses. Lets say foo1 is 0x7ffe1114. Then you'd have:
> 
>    ori r2, r0, 0xabc
>    lui r1, %hi(foo)
>    sw  r2, %lo(foo)(r1)
>    lui r1, %hi(foo1)
>    sw  r2, %lo(foo1)(r1)
> 
> or
> 
>    ori r2, r0, 0xabc
>    lui r1, 0x7ffe
>    sw  r2, 0x1110(r1)
>    sw  r2, 0x1114(r1)
> 
> Here, using compile time constants saved you an insn.

Just off the top of my head, you can have the same benefit given the
linker method:

extern volatile unsigned int foo;

foo = 0;
*( &foo + 4 ) = 0;

on arm this generates:

ldr	r1, [pc, #8]
str	r2, [r1]
str	r2, [r1, #16]


I'm guessing i get PC relative addressing because this is a small
program where foo is only referenced in one place, but i dont really
know. It seems to do this in my small test program regardless of the
complexity of the address. Also the code clarity just dropped
tremendously :)
 
> --Mark
>