Re: Serious code size regression from 3.0.2 to now

[Geoff Keating <geoffk at geoffk dot org>]

> 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

> On 23 Jul 2002, Geoff Keating wrote:
> 
> > 
> > It sounds like at least one of the problems is that very short
> > sequences of code are being made to each align at the start of a cache line,
> > but if you have (for example, not any particular real processor)
> > 
> >         .align 5
> >         mov r0,#1
> >         b L123
> >         .align 5
> >         mov r0,#2
> >         b L124
> > ...
> > 
> > you don't need the second '.align', since the next chunk will be fully
> > contained in a cache line.
> > 
> > If this is done properly, most short code sequences won't need extra
> > alignment...
> > 
> > One tricky bit is that sometimes multiple alignments are helpful, for instance
> > 
> >         .align 5
> >         b L123
> >         .align 5
> >         mov r0,#2
> >         b L124
> > 
> > the middle '.align' might need to be a '.align 3' (rather than
> > deleted) if it will help to keep code aligned to two-instruction
> > boundaries.  This is still much better than the original, though.
> > 
> > This would be a helpful project.  Perhaps it should go on the projects page?
> > 
> > 
> 
> Doh, I forgot to "Reply All" when sending previous message, so I'm
> resending.
> 
> 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.

> 2) Suppress cache alignment for BBRO-generated blocks

That would also be bad.

> Are there any other possible solutiosn?

The real problem here is not that these blocks get cache-aligned, it's
that each block is cache-aligned separately.  One set of padding would
be OK, it's the 94 sets of padding that is bad.  You can see my
suggestion above, which would avoid 93 instances of the padding.

> Also, I propose BBRO be disabled when optimizing for size (-Os).

BBRO generally doesn't add much to the total size.  It's the padding
that is making it costly.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>