Serious code size regression from 3.0.2 to now

tm tm@mail.kloo.net
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 <tm@mail.kloo.net>
> > Cc: Joern Rennecke <joern.rennecke@superh.com>, gcc-bugs@gcc.gnu.org,
> >    stephen.clarke@superh.com, shumpei.kawasaki@hsa.hitachi.com, tm@kloo.net
...
> > 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.

Toshi




More information about the Gcc-bugs mailing list