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.