public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Richard Henderson <rth@redhat.com>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: [RFC] Remove -freorder-blocks-and-partition
Date: Wed, 03 Aug 2011 20:50:00 -0000	[thread overview]
Message-ID: <20110803205015.GC22893@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <4E25F810.6050904@redhat.com>

Hi,
> The worst part is that test coverage for this feature is
> extremely poor.  It's very difficult to tell if any cleanup
> in this area is likely to introduce more bugs than it fixes.
> 
> After 3 days fighting with this code, I had a bit of a 
> cathartic whine on IRC.  I got two votes to just rip the 
> whole thing out.

I am also not fan of the code, given that I had several encounters with it and
was bit by it quite badly, too.

With ipa-split I implemented part of what is needed for outlining of cold
regions of function sinto a separate functions.  This however is different from
partitioning - i.e. the code sequence of getting into the offlined part is
longer since you need to actually pass stuff in function arguments and it is
hard to jump back and forth in between hot and cold regions.
Expecting it the partitioning to be fully replaced by gimple level offlining is 
thus not realistic.

So function partitioning still makes sense to me as an optimization and in fact
I was hoping to get it into shape that it can be enabled with -fprofile-use by
default and thus also tested by profiledbootstrap.  It did not happen as I am
busy with IPA/LTO tasks at the moment.

So I am unsure what really we want to do.  Removing the feature seems pity,
but at the same time the code really needs an revamp. Since you apparently spent
most time to on this issue, I won't object to your decision to rip out the code.

Honza
> 
> Andrew Pinski points out that the feature could probably be
> equivalently implemented via outlining and function calls
> (I assume well back at the gimple level).  At which point we
> no longer have cross-segment jump_insns at the rtl level,
> which seems like a Really Big Win to me at this point.
> Not that I'm volunteering to actually do the work to implement
> any such scheme.
> 
> Thoughts?
> 
> 
> r~

  parent reply	other threads:[~2011-08-03 20:50 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
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 [this message]
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=20110803205015.GC22893@atrey.karlin.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --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).