Re: clean up latch blocks (+rfc)

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

> > > I think it would be much cleaner to just persuade code sinking
> > > not to move statements into empty loop latches (one simple way might
be
> > > to eliminate the latch forwarder blocks before sinking is run, since
> > > sinking will only move the code to the existing blocks).

By the way, we're seeing a similar phenomenon later on in the compiler -
during tree-outof-ssa some copies are inserted into a (previously empty)
latch block. Later on, this prevents the modulo-scheduler at the RTL level
from scheduling the loop. This seems to happen to all vectorizer testcases
that have an unaligned load on powerpc. We generally generate the following
code:

      v0 <-- vload
loop:
      v1 = phi <v0, v2>
      v2 = vload
      vx = realign_load <v1, v2>
      use vx
      if ... goto loop

When going out of ssa, the copy v1=v2 is inserted in the latch block.
Any thought on where is the best place to handle this (is it possible to
tweak tree-outof-ssa? or better try to clean it up just before sms?)

thanks,
dorit


Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> wrote on 11/29/2005
06:30:57 PM:

> Hello,
>
> > > > +     FOR_EACH_SSA_DEF_OPERAND (def_p, stmt, iter, SSA_OP_ALL_DEFS)
> > > > +       {
> > > > +         tree def = DEF_FROM_PTR (def_p);
> > > > +         imm_use_iterator imm_iter;
> > > > +         use_operand_p use_p;
> > > > +
> > > > +         FOR_EACH_IMM_USE_FAST (use_p, imm_iter, def)
> > > > +      {
> > > > +        tree use_stmt = USE_STMT (use_p);
> > > > +        basic_block use_bb = bb_for_stmt (use_stmt);
> > > > +
> > > > +        if (!flow_bb_inside_loop_p (loop, use_bb))
> > >
> > > this is weird.  I don't think this can ever be true -- definitions in
> > > the latch of the loop can only be used in the latch itself, or as an
> > > argument of a phi node of the loop, since the loop latch cannot
dominate
> > > any other location. What you probably want to check is whether you do
> > > not create an overlapping live range by moving the assignments.  But
> > > this is very ugly.
> > >
> > > I think it would be much cleaner to just persuade code sinking
> > > not to move statements into empty loop latches (one simple way might
be
> > > to eliminate the latch forwarder blocks before sinking is run, since
> > > sinking will only move the code to the existing blocks).
> > >
> >
> > sound good to me; looks like before sink_pass make_forwarder_block() is
> > activated by dom_pass (tree_ssa_dominator_optimize() -->
flow_loops_find()
> > --> canonicalize_loop_headers() --> make_forwarder_blocks). Shall we
pass
> > flow_loops_find() and canonicalize_loop_headers() a flag that indicates
> > whether to activate make_forwarder_block() for latches?
>
> actually, you get the empty blocks in sink_pass from spliting critical
> edges before pre, so it would be necessary to clean them up in sinking
> (just calling remove_forwarder_block for all predecessors of backedges
> in cfg).
>
> Zdenek