This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]