This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Reduce complette unrolling & peeling limits
- From: Richard Biener <rguenther at suse dot de>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Eric Botcazou <ebotcazou at adacore dot com>, gcc-patches at gcc dot gnu dot org, jakub at redhat dot com
- Date: Thu, 6 Dec 2012 10:31:13 +0100 (CET)
- Subject: Re: Reduce complette unrolling & peeling limits
- References: <20121114233407.GC12910@kam.mff.cuni.cz> <20121119124644.GA7359@kam.mff.cuni.cz> <20121121162535.GA32567@kam.mff.cuni.cz> <3865511.3OVQ0YimXj@polaris> <20121204182744.GA2493@kam.mff.cuni.cz>
On Tue, 4 Dec 2012, Jan Hubicka wrote:
> > > here is updated patch. It should get the bounds safe enough to not have
> > > effect on codegen of complette unrolling.
> > >
> > > There is IMO no way to cut the walk of loop body w/o affecting codegen in
> > > unrolling for size mode. The condition on unroling to happen is
> > >
> > > unrolled_size * 2 / 3 < original_size
> > >
> > > The patch makes the function walking body to stop after minimal number of
> > > duplicated insns is large (PARAM_MAX_COMPLETELY_PEELED_INSNS). The formula
> > > above allows unlimited duplication when loop body is large enough. This is
> > > more a bug than feature, so I think it is safe to alter it.
> > >
> > > Bootstrapped/regtested x86_64-linux, OK?
> > >
> > > Honza
> > >
> > > * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Add UPPER_BOUND
> > > parameter.
> > > (try_unroll_loop_completely) Update.
> >
> > The patch hasn't been installed, has it? The test still takes 20s to compile
> > at -O3 on a fast x86-64 box, so you can imagine what this yields on slower
> > machines (and that's before the x4 because of the various dg-torture options).
>
> Yes, I need approval for this one.
> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01798.html
Ok.
Thanks,
Richard.