Re: [patch] Preserving loops in threading (updated)

[Dorit Nuzman <DORIT at il dot ibm dot com>]

> Hello,
>
> > Zdenek Dvorak wrote on 04/19/07 11:14:
> >
> > > --- 5898,5916 ----
> > >   static unsigned int
> > >   execute_vrp (void)
> > >   {
> > > !   loop_optimizer_init (LOOPS_NORMAL | LOOPS_HAVE_RECORDED_EXITS);
> > >     if (current_loops)
> > > !     {
> > > !       rewrite_into_loop_closed_ssa (NULL, TODO_update_ssa);
> > > !       scev_initialize ();
> > > !     }
> > > !
> > > !   insert_range_assertions ();
> >
> > Why do we need this?  For the jump threading during replacement after
VRP?
>
> this change is actually independent on the rest of the patch (I
> overlooked this); LOOPS_HAVE_RECORDED_EXITS and
> rewrite_into_loop_closed_ssa is added since scev more or less assumes
> them (it is able to work without them, but in some cases it will provide
> suboptimal results)
>
> > > + /* Internally used for the first instance of a pass.  */
> > > + #define TODO_mark_first_instance   (1 << 16)
> > > +
> >
> > Not clear to me why you need this?
>
> See the discussion in
> http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01740.html (point 2), and
> the followup mails.  Basically, jump threading may result in peeling the
> loops.  There is no way how to prevent this completely, as in the cases
> when this happens, it is a profitable transformation.  However, if
> we peel one iteration of the loop every time vrp or dom is run, we end
> up peeling something like 6 iterations of each loop, which is somewhat
> unexpected, and it has some negative effects: it increases code size,
> and often it may force e.g. vectorizer to work harder on fixing the
> alignment of arrays.
>
> For these reasons, the patch restricts this kind of transformations
> to just the first instance of dom pass (and contains a heuristics
> to avoid peeling single-block loops completely, so that vectorizer is
> happy).
>

I just happened to notice that the loop in gcc.dg/vect/vect-iv-4.c gets
peeled after all. Any idea why (given that it's a single-basic-block loop)?

(Also I wonder about the prospects of extending this restriction to
vectorizable outer-loops, when the time comes...?)

dorit

> Zdenek