This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Remove -freorder-blocks-and-partition


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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]