From: Jan Hubicka <hubicka@ucw.cz>
To: Xinliang David Li <davidxl@google.com>
Cc: Jan Hubicka <hubicka@ucw.cz>, Paolo Bonzini <bonzini@gnu.org>,
Richard Henderson <rth@redhat.com>,
"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: [RFC] Remove -freorder-blocks-and-partition
Date: Thu, 04 Aug 2011 13:32:00 -0000 [thread overview]
Message-ID: <20110804133214.GB12248@kam.mff.cuni.cz> (raw)
In-Reply-To: <CAAkRFZKq_BDo4bA3nVOQwPtns_38pMQ0J0tzdRk1gV9hjuj4ug@mail.gmail.com>
> On Wed, Aug 3, 2011 at 2:06 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
> >> In xalancbmk, with the partition option, most of object files have
> >> nonzero size cold sections generated. The text size of the binary is
> >> increased to 3572728 bytes from 3466790 bytes. Â Profiling the program
> >> using the training input shows the following differences. With
> >> partitioning, number of executed branch instructions slightly
> >> increases, but itlb misses and icache load misses are significantly
> >> lower compared with the binary without partitioning.
> >>
> >>
> >> David
> >>
> >> With partition:
> >> -----------------
> >> Â Â 53654937239 Â branches
> >> Â Â Â 306751458 Â L1-icache-load-misses
> >> Â Â Â Â 8146112 Â iTLB-load-misses
> >
> > Note that I was also planning for some time to introduce notion of provably cold
> > stuff into our branch prediction heurstics. I.e. code leading to aborts, eh etc
>
> no-return attribute is looked at by static profile estimation pass. Is
> the attribute (definitely not returning) properly propagated to the
> callers (wrappers of exit, etc)?
It is, at local pure const and IPA pure const. Catch with IPA pure const is
that profile is computed at tha time and it is not updated afterwards, so when
discovered late it does not affect static profile estimates (yet), only gets
cfg/codegen better.
Honza
>
> David
>
> > that can be then offlined even w/o profile feedback and could perhaps help
> > to large apps.
> > (also the whole pass should be more effective with larger testcases, SPEC2k6 is slowly
> > becoming a small one)
> >
> > Honza
> >
next prev parent reply other threads:[~2011-08-04 13:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-19 21:43 Richard Henderson
2011-07-19 21:56 ` Bernd Schmidt
2011-07-19 22:09 ` Richard Henderson
2011-07-19 23:18 ` Joern Rennecke
2011-07-19 22:28 ` Joern Rennecke
2011-07-19 22:44 ` Richard Henderson
2011-07-25 7:40 ` Xinliang David Li
2011-07-25 11:05 ` Paolo Bonzini
2011-07-25 18:40 ` Xinliang David Li
2011-07-26 1:29 ` Xinliang David Li
2011-07-26 2:33 ` Joern Rennecke
2011-07-27 6:47 ` Xinliang David Li
2011-07-27 8:12 ` Paolo Bonzini
2011-08-03 21:06 ` Jan Hubicka
2011-08-03 21:46 ` Xinliang David Li
2011-08-04 13:32 ` Jan Hubicka [this message]
2011-08-04 13:39 ` Jan Hubicka
2011-08-04 16:03 ` Taras Glek
2011-08-03 20:56 ` Jan Hubicka
2011-08-03 20:50 ` Jan Hubicka
2011-07-19 22:43 Steven Bosscher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110804133214.GB12248@kam.mff.cuni.cz \
--to=hubicka@ucw.cz \
--cc=bonzini@gnu.org \
--cc=davidxl@google.com \
--cc=gcc@gcc.gnu.org \
--cc=rth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).