Re: Reordering of functions

Tim Frink <plfriko@yahoo.de>
Thu, 21 Feb 2008 09:53:21 +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:53:21 +0100
Organization: CS Department, University of Dortmund, Germany
References: 08-02-051 08-02-052
Keywords: optimize, architecture
Posted-Date: 24 Feb 2008 00:39:16 EST

Hi,


> Function reordering depends heavily on the size of the functions, in
> most cases such a reordering goes hand in hand with the
> profile-information, and the latter is usually targeted at a "main"
> application. whether such code-positioning makes sense, can't be said
> definitely. Pettis/Hansen state in their paper, that such an
> interprocedural optimization combined with bb-positioning within
> functions may be very promising allowing gains from 2 to 15 %
> depending on the application.


yes, but the gain they achieve has two reasons:


1) they use a direct-mapped instruction cache and the contiguously
placement of functions which call each other frequently might avoid
conflict cache misses since these functions are not mapped to the
same cache locations after reordering (I excluded this option in
my assumption)
2) they assume that the number of page faults will be minimized
since functions which call each other frequently will be likely
stored in the same page.


While writing this here another issue comes to my mind. When virtual
memory is used a reordering of functions might influence the TLB (if this
"cache" is not disabled) leading to different program execution.


> In fact, most compiler/frameworks support function-inlining which may
> lead to even bigger functions, which again may lead to a cache being
> to small to hold more than just one function, in such cases such a
> reordering does not make much sense. the one could turn off inlining,
> this may cause a slight efficiency- improvement and together with the
> inner-procedural placement-strategies be of more meaning, but whether
> it would be better if you had inlining turned on is an other question.


Well, this does not answer my question. ;-)
Sure, when a function is completely inlined into the code than its
position in the code is irrelevant. However, a compiler will not inline
large functions (you told the reason with caches) so that the question
of their placement in memory still remains.


Tim


Post a followup to this message

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