This is the mail archive of the
mailing list for the GCC project.
Re: Worse code after bbro?
- From: Jeff Law <law at redhat dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>, Richard Biener <rguenther at suse dot de>
- Cc: Senthil Kumar Selvaraj <senthilkumar dot selvaraj at microchip dot com>, gcc at gcc dot gnu dot org, Jan Hubicka <hubicka at ucw dot cz>
- Date: Wed, 4 Jan 2017 08:49:49 -0700
- Subject: Re: Worse code after bbro?
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <alpine.LSU.firstname.lastname@example.org> <20170104104656.GE28613@gate.crashing.org>
On 01/04/2017 03:46 AM, Segher Boessenkool wrote:
I superficially looked at this a little while ago and concluded that
it's something we ought to be able to handle. However, it wasn't
critical enough to me to get familiar enough with the bbro code to
deeply analyze -- thus I put it into my gcc-8 queue.
On Wed, Jan 04, 2017 at 10:05:49AM +0100, Richard Biener wrote:
The code size is identical, but the trunk version executes one more
instruction everytime the loop runs (explicit jump to .L5 with trunk vs
fallthrough with 4.8) - it's faster only if the loop never runs. This
happens irrespective of the memory clobber inline assembler statement.
With -Os you've asked for smaller code, not faster code.
All of the block reordering is based on heuristics -- there is no polynomial
time and space algorithm to do it optimally, let alone the linear time and
space we need in GCC -- so there always will be cases we do not handle
optimally. -Os does not get as much attention as -O2 etc., as well.
OTOH this seems to be a pretty common case that we could handle. Please
open a PR to keep track of this?
I belive that doing BB reorder in CFG layout mode is fundamentally
flawed but I guess it's wired up so that out-of-CFG layout honors
Why is this fundamentally flawed? The reordering is much easier this way.
Agreed (that we ought to be doing reordering in CFG layout mode).