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: [patch] Fix PR43464: update loop closed SSA form once copy prop is done


Hi,

> > > > On Fri, Mar 26, 2010 at 04:51, Richard Guenther <rguenther@suse.de> wrote:
> > > > > But we already analyzed that copyprop is _not_ the problem. ?The
> > > > > problem is the pass that introduces the two-arg loop-closed PHI
> > > > > node.
> > > > 
> > > > Note that pass_tree_unswitch is not the only pass that introduces
> > > > the two-arg loop-closed PHI.  Copyprop is another pass that does that,
> > > > as it has a TODO_cleanup_cfg that calls cleanup_tree_cfg.
> > > > 
> > > > cleanup_tree_cfg_noloop called from cleanup_tree_cfg is destroying the
> > > > CFG structure needed for the LCSSA form: it removes all the single entry
> > > > basic blocks that were placed after the loops for the LCSSA form.
> > 
> > I am not sure what you refer to here.  LCSSA guarantees you that no value
> > defined inside loop is used outside of it (with the convention that arguments
> > of phi nodes are taken to be used in the source block of the corresponding
> > edge).  However, it does not guarantee that the phi nodes inserted for this
> > purpose have just a single argument.
> > 
> > So, if your code relies on this property, you will have to ensure that this is the
> > case yourself (by splitting the exit edges),
> 
> 
> So in fact the code in copyprop that tries to preserve LCSSA PHI nodes
> is bogus:
> 
>           if (!is_gimple_reg (def)
>               /* In loop-closed SSA form do not copy-propagate through
>                  PHI nodes.  Technically this is only needed for loop
>                  exit PHIs, but this is difficult to query.  */
>               || (current_loops
>                   && gimple_phi_num_args (phi) == 1
>                   && loops_state_satisfies_p (LOOP_CLOSED_SSA)))
>             prop_set_simulate_again (phi, false);
>           else
>             prop_set_simulate_again (phi, true);
> 
> as it does so only for single-arg PHIs.  Given the comment, can
> we easily detect LCSSA PHI nodes?

sure -- just check whether at least one predecessor edge of the block in that the phi node is located
is a loop exit (this is unnecessarily conservative, of course, but so is the current code),

Zdenek


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