This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Preserve loops from CFG build until after RTL loop opts
- From: Richard Biener <rguenther at suse dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, tom at codesourcery dot com
- Date: Fri, 26 Apr 2013 10:02:39 +0200 (CEST)
- Subject: Re: [PATCH] Preserve loops from CFG build until after RTL loop opts
- References: <alpine dot LNX dot 2 dot 00 dot 1304251607460 dot 7969 at zhemvz dot fhfr dot qr> <20130425142754 dot GG28963 at tucnak dot redhat dot com>
On Thu, 25 Apr 2013, Jakub Jelinek wrote:
> On Thu, Apr 25, 2013 at 04:19:20PM +0200, Richard Biener wrote:
> > This is the patch that I consider final as a first step (to avoid
> > changing too much at once). I've analyzed the few failures
> > and compared to the previous patch changed the tree-ssa-tailmerge.c
> > part to deal with merging of loop latch and loop preheader (even
> > if that's a really bad idea) to not regress gcc.dg/pr50763.c.
> > Any suggestion on how to improve that part welcome.
> > I've had to change a few testcases, mostly in parts that are not
> > really related to what they check (also reverting to a previous
> > testcase state). One remaining failure is
> > FAIL: gcc.dg/pr53265.c (test for bogus messages, line 147)
> > which I don't want to deal with in this patch. I can either
> > followup or prepare the discussed fix of adding a copyprop
> > pass before cunrolli. Another possibility is to XFAIL the above.
> As that testcase was derived from real-world code (gcc itself, if I remember
> well two places actually hitting it at that point), I'd strongly prefer
> the former, rather than XFAIL, because people would be pretty much annoyed
> by the false positive warning, scratching heads where they invoke undefined
> behavior when they actually don't. But sure, it can wait for a follow-up
> > Bootstrapped and tested on x86_64-unknown-linux-gnu for all languages
> > including Ada (including 32bit multilibs).
> > Ok for trunk?
> Yes, thanks.
A bootstrap & test together with the additional copyprop pass did not
show any issues so the following is what I committed in addition
to the patch.
* passes.c (init_optimization_passes): Schedule a copy-propagation
pass before complete unrolling of inner loops.
--- gcc/passes.c (revision 198332)
+++ gcc/passes.c (working copy)
@@ -1397,6 +1397,7 @@ init_optimization_passes (void)
They ensure memory accesses are not indirect wherever possible.
+ NEXT_PASS (pass_copy_prop);
/* After CCP we rewrite no longer addressed locals into SSA