Hi,
On Fri, 2 Dec 2011, William J. Schmidt wrote:
> > > - tree def = gimple_get_lhs (stmt);
> > > + /* If this is a PHI, we only want to consider it if all of its
> > > + arguments are SSA names (which are known to be defined in a
> > > + single place). This avoids errors when dealing with if-temps,
> > > + for example. */
> > > + if (gimple_code (stmt) == GIMPLE_PHI)
> > > + for (i = 0; i < gimple_phi_num_args (stmt); i++)
> > > + if (TREE_CODE (gimple_phi_arg_def (stmt, i)) != SSA_NAME)
> > > + return;
> >
> > Can you elaborate on this? Why are for example constants not ok
> > (which are the only things besides SSA names that should occur
> > here)?
>
> I ran into a bootstrap problem in gengtype.c without this that took me a
> while to track down. Control flow was like this:
>
> 10
> / |
> 11 |
> \ |
> 12
> / |
> 13 |
> \ |
> 14
>
> Blocks 12 and 14 contained iftmp PHI statements of constants that looked
> identical, but the constants were "defined" in different blocks. Blocks
> 11 and 13 were empty.
>
> In block 12:
>
> iftmp.132_1 = PHI<", "(10), ""(11)>;
>
> In block 14:
>
> iftmp.133_7 = PHI<", "(12), ""(13)>;
You never can regard same-looking PHI nodes from different blocks as
equivalent. Checking for non-SSA-names is not sufficient, the arguments
need to have the same control dependence. Replace the above constants
with SSA names to see it breaking too (assume x_2 and x_3 are defined at
function start for instance):
bb12
iftmp.132_1 = PHI<x_2(10), x_3(11)>;
bb14:
iftmp.133_7 = PHI<x_2(12), x_3(13)>;
Again, if the two conditions in bb10 and bb12 are different the phi
results will be different (x_2 vs x_3). I'd punt and simply deal only
with PHI nodes in the current block, i.e. don't remember any PHI states
during the walking.
Ciao,
Michael.
