On Fri, 2011-12-02 at 14:59 +0100, Michael Matz wrote: > 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. >
Ah, of course, you're right. I wasn't thinking about that properly. I'll revisit this. Thanks, Bill > > Ciao, > Michael. >