This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 1/3] function: Do the CLEANUP_EXPENSIVE after shrink-wrapping, not before
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 17 May 2016 17:22:54 -0500
- Subject: Re: [PATCH 1/3] function: Do the CLEANUP_EXPENSIVE after shrink-wrapping, not before
- Authentication-results: sourceware.org; auth=none
- References: <213485283eede9da12b217737d95fc8f5c4be442 dot 1463428211 dot git dot segher at kernel dot crashing dot org> <1831730 dot xXXSthoG5j at polaris> <20160517084654 dot GB18363 at gate dot crashing dot org> <20909191 dot oPg4YIUu4L at polaris> <20160517091758 dot GC18363 at gate dot crashing dot org>
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