This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Small cleanups
- From: Richard Guenther <rguenther at suse dot de>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, trevor_smigiel at playstation dot sony dot com, andrew_pinski at playstation dot sony dot com
- Date: Fri, 13 Mar 2009 10:30:38 +0100 (CET)
- Subject: Re: [PATCH] Small cleanups
- References: <200903122003.n2CK3HGj013630@d12av02.megacenter.de.ibm.com>
On Thu, 12 Mar 2009, Ulrich Weigand wrote:
> Richard Guenther wrote:
>
> > 2008-08-01 Richard Guenther <rguenther@suse.de>
> >
> > * tree-ssa-pre.c (fini_pre): Take in_fre parameter. Free
> > loop information only if we initialized it.
> > (execute_pre): Call fini_pre with in_fre.
> > * tree-ssa-loop-ivcanon (try_unroll_loop_completely): Dump
> > if we do not unroll because we hit max-completely-peeled-insns.
> > Use our estimation for consistency, do allow shrinking.
>
> > + if (unr_insns > ninsns
> > + && (unr_insns
> > + > (unsigned) PARAM_VALUE (PARAM_MAX_COMPLETELY_PEELED_INSNS)))
> > + {
> > + if (dump_file && (dump_flags & TDF_DETAILS))
> > + fprintf (dump_file, "Not unrolling loop %d "
> > + "(--param max-completely-peeled-insns limit reached).\n",
> > + loop->num);
> > + return false;
> > + }
>
> Before this patch, the PARAM_MAX_COMPLETELY_PEELED_INSNS parameter
> was always considered to limit the number of insns *added* by loop
> unrolling, as I understand (and this still seems to be the case in
> loop-unroll.c). Your new check, however, compares the *total* number
> of instructions after loop unrolling (including the initial copy)
> against the parameter.
>
> Was this a deliberate change? I'm wondering if the check shouldn't
> rather be something along the lines of
>
> if (unr_insns > ninsns
> && (unr_insns - ninsns
> > (unsigned) PARAM_VALUE (PARAM_MAX_COMPLETELY_PEELED_INSNS)))
It wasn't a deliberate change. Does it cause any problems for you?
Thanks,
Richard.