This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Hot and Cold Partitioning (Was: GCC 4.1 Projects)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Joern RENNECKE <joern dot rennecke at st dot com>
- Cc: Dale Johannesen <dalej at apple dot com>, gcc at gcc dot gnu dot org, Mark Mitchell <mark at codesourcery dot com>, ctice at apple dot com
- Date: Mon, 28 Feb 2005 13:53:08 +0100
- Subject: Re: Hot and Cold Partitioning (Was: GCC 4.1 Projects)
- References: <421F64CA.6010008@st.com> <F34354DA-8758-11D9-8055-000393D76DAA@apple.com> <422311F7.8080800@st.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Feb 28, 2005 at 12:43:35PM +0000, Joern RENNECKE wrote:
> Well, even then, using of the cold section can increase the hot section
> size, depending on target, and for some
> targets the maximum supported distance of the cold section.
>
> For SH, using the cold section, you get (for non-PIC):
>
> L2: mov.l 0f,rn
> jmp @rn
> nop
> .balign 4
> 0: .long L3
>
> .coldsection:
> L3: mov.l 0f,rn
> jmp @rn
> mov #0,rn
> .balign 4
> 0: .long L1
>
> I.e. 10 to 12 bytes each in in hot and cold sections.
>
> Without the cold section, you need only 4 bytes:
> L2: bra L1
> mov #0,rn
>
> Note also, that in order to avoid the condjump-around-jump syndrome, L2 has
> to be within about +-256 bytes of the condjump.
> Should I do custom basic block reordering in machine_dependent_reorg to
> clean up
> the turds of hot and cold partitioning?
Its nothing SH specific, this particular example I'd say results in bigger code
in hot section on almost all arches.
The hot&cold partitioning patch simply must have some low bounds on how big
a cold BB must be if moving it to cold partition is worthwhile.
Jakub