This is the mail archive of the
mailing list for the GCC project.
Re: Fixes to estimate_num_insns from pretty-ipa branch
> On Thu, Apr 9, 2009 at 4:18 PM, Jan Hubicka <email@example.com> wrote:
> > Index: tree-ssa-loop-ivcanon.c
> > ===================================================================
> > --- tree-ssa-loop-ivcanon.c ? ? (revision 145799)
> > +++ tree-ssa-loop-ivcanon.c ? ? (working copy)
> > @@ -136,8 +136,8 @@ tree_num_loop_insns (struct loop *loop,
> > ? ?1) exit condition gets removed (2 insns)
> > ? ?2) increment of the control variable gets removed (2 insns)
> > ? ?3) All remaining statements are likely to get simplified
> > - ? ? ?due to constant propagation. ?Hard to estimate; just
> > - ? ? ?as a heuristics we decrease the rest by 1/3.
> > + ? ? ?due to constant propagation and optimization on memory stores.
> > + ? ? ?Hard to estimate; just as a heuristics we decrease the rest by 1/3.
> > ? ?NINSNS is the number of insns in the loop before unrolling.
> > ? ?NUNROLL is the number of times the loop is unrolled. ?*/
> > @@ -149,7 +149,7 @@ estimated_unrolled_size (unsigned HOST_W
> > ? HOST_WIDE_INT unr_insns = 2 * ((HOST_WIDE_INT) ninsns - 4) / 3;
> > ? if (unr_insns <= 0)
> > ? ? unr_insns = 1;
> > - ?unr_insns *= (nunroll + 1);
> > + ?unr_insns *= nunroll;
> This looks wrong. If the loop is unrolled once (nunroll == 1) we want
> to multpliy unr_insns by 2.
nunroll is initialized to niter. For loop
niter is 2 and so is nunroll, but we don't want to multiply code size
estimate by 3.
There seems always a bit of confusion about if nunroll means number of
body copies at the end of unrolling process or number of new copies.
I can also add -1 to caller of estimated_unrolled_size if it seems more