Subject: Re: Strange C compiler code generation
To: Peter Teichmann <teich-p@Rcs1.urz.tu-dresden.de>
From: Richard Earnshaw <rearnsha@arm.com>
List: port-arm32
Date: 02/26/2001 18:59:40
> This seems to be reasonable as it has no impact on the speed, if the structure
> itself is assumed to be always 32-Bit aligned.

It's not an issue of speed; it's an issue of correctness for many existing 
programs.

> 
> > Or ldrh on ARMv4!
> 
> But not on that stupid RiscPC I have, even if it has a SA processor!

Don't I know it :-(

> It seems to turn out that they are not necessary there, it was just easier to
> pack all structures, even those where it is not needed.

It seems the original programmer has committed one of the seven deadly 
sins (sloth).

> But the actual C compiler under NetBSD does by default (if there is no
> #pragma pack(..) assumes that structures are 32-Bit aligned. BTW, is
> #pragma pack ANSI C or is it some GCC extension?

It's part of System V, but it is widely recognized on other systems as 
well.

> Another question:
> 
> I found that GCC is using the possibility to conditionally execute all ARM
> instructions only in very rare cases, and sometimes also does a bad job with
> optimizing in some cases.
> 
> E.g. one can find:
> 
> MOV r1,#1
> ORR r3,r3,r7,lsl r1

Known problem -- the code is right until after we allocate registers, then 
some pesky algorithm comes along and says to itself "registers are always 
cheap, and I have that value in a register -- I'll use it here.  What do 
you mean registers aren't always as cheap as constants?"

I keep meaning to fix it, but it isn't at the top of my priority list.

> Also it is not able to compile
> 
> if (a>0x000000ff) {
>   a >>= 8;
>   n +=8;
> }
> 
> and get:
> 
> CMP     a,#0x000000ff
> MOVHI   a,a,lsr#8
> ADDHI   n,n,#8
> 
> No, gcc needs to use a jump instruction!

Gcc 3.0 will be much better at this, it has a full optimization pass that 
looks for blocks of code that can be conditionally executed instead of a 
simple state machine hidden in the back-end.  It's not perfect yet: 
sometimes it generates sequences that are longer than the recommended 
limit for the processor; it can't handle conditional compares; and it 
can't handle cases where the condition code is clobbered on the last 
conditional insn.  But other than that, it does find more sequences than 
we used to.

> 
> Do you know a person who is involved in this? 

Yep.  Me.

Richard.