This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [autovect] [patch] clean up latch blocks (+rfc)
- From: Dorit Naishlos <DORIT at il dot ibm dot com>
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 29 Nov 2005 18:01:59 +0200
- Subject: Re: [autovect] [patch] clean up latch blocks (+rfc)
Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> wrote on 11/29/2005
04:43:09 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?
thanks,
dorit
> Zdenek
>