[PATCH 1/3] function: Do the CLEANUP_EXPENSIVE after shrink-wrapping, not before

[Segher Boessenkool]

On Tue, May 17, 2016 at 04:17:58AM -0500, Segher Boessenkool wrote:
> On Tue, May 17, 2016 at 11:08:53AM +0200, Eric Botcazou wrote:
> > > How would it?  The shrink-wrapping algorithms do not much care how you
> > > write your control flow.  The only things I can think of are drastic
> > > things like removing some dead code, or converting a switch to a direct
> > > jump, but those had better be done for the immediately preceding passes
> > > already (register allocation).
> > 
> > But the compiler didn't wait until after shrink-wrapping to emit multiple 
> > epilogues and can still do that w/o shrink-wrapping.
> 
> It will only ever generate a single epilogue (unless you also count
> sibcall epilogues), and that is done after shrink-wrapping.  Or you mean
> something else and I just don't see it.
> 
> > > I can put back a  cleanup_cfg (0)  in front if that seems less tricky
> > > (or just safer)?
> > 
> > I think you need to evaluate the effects of the change on a set of sources.
> 
> Yeah I'll do that, thanks for the idea.

I built cross-compilers for 30 targets, and built Linux with that.
6 of those failed for unrelated reasons.  Of the 24 that do build,
five show a few insns difference between having a cleanup_cfg before
shrink-wrapping or not (CLEANUP_EXPENSIVE made no difference there).
These targets are s390, blackfin, m68k, mn10300, nios2.

It turns out that prepare_shrink_wrap *does* care about block structure:
namely, it only moves insns from the "head" block to a successor.  It
then makes a difference when the cleanup_cfg can merge two successor blocks
(say, the first is a forwarder block).  This happens quite seldomly.

So, shall I put a cleanup_cfg back before shrink-wrapping?

[ I'm now also looking at what patch #3 (and #2) change; also small stuff ].


Segher