This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Small cleanups
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: rguenther at suse dot de (Richard Guenther)
- 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: Thu, 12 Mar 2009 21:03:17 +0100 (CET)
- Subject: Re: [PATCH] Small cleanups
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)))
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com