This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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