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.