This is the mail archive of the
mailing list for the binutils project.
Re: Performance bug while ordering .text sections by default in gold.
- From: Sriraman Tallam <tmsriram at google dot com>
- To: binutils <binutils at sourceware dot org>, Ian Lance Taylor <iant at google dot com>, Cary Coutant <ccoutant at google dot com>, Easwaran Raman <eraman at google dot com>, David Li <davidxl at google dot com>
- Date: Tue, 22 Jan 2013 15:00:46 -0800
- Subject: Re: Performance bug while ordering .text sections by default in gold.
- References: <CAAs8HmyDG97UquEf6nvovmV68zzHJaM6xk2Enm+3EZt-DTwaWQ@mail.gmail.com>
For context, this performance regression was observed with non-fdo
builds, no profiles, where some text sections got marked with
.text.unlikely triggering the function re-ordering in ".text". This
is a case where such re-ordering even with the fix might not be better
than the default since the compiler is not basing the section names on
actual profiles. Is it ok to add an option, like --no-text-reordering,
to gold to be able to turn this off.
On Tue, Jan 22, 2013 at 11:35 AM, Sriraman Tallam <email@example.com> wrote:
> This patch to gold :
> http://sourceware.org/ml/binutils/2012-12/msg00227.html introduces
> unnecessary behaviour while ordering text sections and this is causing
> performance regressions in some benchmarks. The intent of this patch
> was to group .text sections with special prefixes like ".text.hot",
> ".text.unlikely" , ".text.startup" together, which it achieves.
> However, it does other undesired things too like sorting section names
> of those sections without these special prefixes. This is because it
> uses the compare function "Input_section_sort_compare" which was used
> to sort ".ctors" and ".dtors". Sorting by section names can cause
> undesired ordering like splitting functions in the same module.
> I am fixing this by making ".text" default sorting use the sort
> function Input_section_sort_section_order_index_compare. I think this
> is better as the different comparison criteria are much less and is
> all applicable to ".text" under different contexts.
> Patch attached.