Re: Reordering of functions

Tim Frink <plfriko@yahoo.de>
Thu, 21 Feb 2008 09:41:38 +0100

          From comp.compilers

Related articles
Reordering of functions plfriko@yahoo.de (Tim Frink) (2008-02-18)
Re: Reordering of functions nkim@odmsemi.com (Nikolai Kim) (2008-02-18)
Re: Reordering of functions bisqwit@iki.fi (Joel Yliluoma) (2008-02-19)
Re: Reordering of functions cfc@shell01.TheWorld.com (Chris F Clark) (2008-02-19)
Re: Reordering of functions gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-02-20)
Re: Reordering of functions plfriko@yahoo.de (Tim Frink) (2008-02-21)
Re: Reordering of functions plfriko@yahoo.de (Tim Frink) (2008-02-21)
Re: Reordering of functions plfriko@yahoo.de (Tim Frink) (2008-02-21)
Re: Reordering of functions gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-02-24)
Re: Reordering of functions cfc@shell01.TheWorld.com (Chris F Clark) (2008-02-24)
Re: Reordering of functions Jan.Vorbrueggen@thomson.net (=?ISO-8859-15?Q?Jan_Vorbr=FCggen?=) (2008-02-25)
Re: Reordering of functions gneuner2@comcast.net (George Neuner) (2008-02-25)
| List of all articles for this month |
From: Tim Frink <plfriko@yahoo.de>
Newsgroups: comp.compilers
Date: Thu, 21 Feb 2008 09:41:38 +0100
Organization: CS Department, University of Dortmund, Germany
References: 08-02-051 08-02-054
Keywords: optimize, architecture
Posted-Date: 24 Feb 2008 00:39:02 EST

> Aren't "with branch prediction" and "caches are disabled" somewhat
> mutually exclusive statements?


Depends. When you think of a branch target buffer then you are correct.
This buffer is a small cache which holds branch targets previously
computed. But there are also static branch predictions which just
rely on the instruction and the jump direction. For example,
conditional jumps with a backward displacement might be always predicted
as taken. Here the buffering of the branch target might be omitted.


> Function reordering might help also in situations where the processor
> supports jumps that are differently encoded depending on the jump length
> (such as the bra/brl opcodes on 65c816, or similar on x86). If a tailcall
> occurs to a function that is located within a short distance, it might
> be faster with than a tailcall with a larger distance, because the opcodes
> differ.


OK, I agree, that's a good point.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.