Serious code size regression from 3.0.2 to now
Tue Jul 23 21:16:00 GMT 2002
On Tue, 23 Jul 2002, Geoff Keating wrote:
> > Date: Tue, 23 Jul 2002 16:22:18 -0700 (PDT)
> > From: tm <email@example.com>
> > Cc: Joern Rennecke <firstname.lastname@example.org>, email@example.com,
> > firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
> > The culprit appears to be the basic block reordering pass. These
> > cache-aligned blocks with only two instructions only appear after
> > BBRO. BBRO seems to determine these isntructions are unlikely to be
> > executed, and pulls them out-of-line into their own separate code block.
> Yes, that's how it's supposed to work.
> > Unfortunately, these code blocks later become cache-aligned.
> That is also not a bad thing. If the code blocks were very
> infrequently executed, there'd be no benefit, but they may be
> executed, say, 20% of the time.
> > I can see two possible solutions for this problem:
> > 1) Tweak BBRO heuristics to prevent out-of-lining short code sequences
> > of less than n insns
> That would be a significant de-optimisation.
Not necessarily. On the SH4 we can branch over single instructions
with no penalty because it conditionally executes the one instruction on
the inverse of the branch condition.
So if n is set to 2, then it would be a big win on the SH4.
Also, this would be a big win for the ARM as well because the same
situation should occur. BBRO is probably pulling single instructions
out-of-line which prevents later passes from generating conditionally
executed single instructions.
More information about the Gcc-bugs