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 PR middle-end/39976, 200.sixtrack degradation



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.
> 


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