This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Worse code after bbro?
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: 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 04:46:57 -0600
- Subject: Re: Worse code after bbro?
- Authentication-results: sourceware.org; auth=none
- References: <87zijpcysb.fsf@microchip.com> <alpine.LSU.2.11.1701041003130.5294@t29.fhfr.qr>
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
> EDGE_FALLTHRU.
Why is this fundamentally flawed? The reordering is much easier this way.
> In any way, why does BB reorder not "fix" the "bogus" reorder
> into-CFG-layout performs?
I'm not sure what bogus reorder you're talking about here?
cfg_layout_initialize should not reorder anything (other than the usual
things cleanup_cfg does)?
Segher