This is the mail archive of the gcc@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: [tree-ssa] New regressions as of 2003-11-04


On Tue, 2003-11-04 at 16:25, Andrew MacLeod wrote:
> On Tue, 2003-11-04 at 16:17, law@redhat.com wrote:
> > In message <1067979853.7039.50.camel@p4>, Andrew MacLeod writes:
> 
> >  >
> >  >Aren't we doing any threading during cleanup_tree_cfg()?
> > You can't thread those jumps because the the target has a PHI node.  If
> > you threaded them you'd generate something like
> > 
> > # block 2
> > if (set != -1)
> >   {
> >     goto lab;
> >   }
> > else
> >   {
> >     goto lab;
> >   }
> > 
> > 
> > lab:
> >   set_1 = PHI (-1 (2), 0 (2))
> > 
> > Which causes all kinds of headaches :(
> > 
> Hrm. Thats bad.
> 
> 
> So that means threading ought to guarantee that there in no more than
> one jump between the else block and the PHI node tho
> 
>  In that case perhaps remove_useless_stmts_and_vars_cond() needs to know
> that this can happen... it had to be modified (has to be?? :-) to look
> for a single stmt in the target of the COND_EXPR arm now, if that block
> contains nothing but a GOTO and a single stmt in the *next* block, then
> it has the same situation.
> 
> Unfortunately, I would think thats the right place in this Brave New
> World we have.
> 
> Wonder how many more of these we'll stumble upon.
> 
Hold on..

Has remove_useless_stmts_and_vars_cond() been modified since/during
lowering?  it pretty much has to be since there is never anything
actually *IN* the arms now, so it oughta be looking in the target block,
and it wouild pick this up wouldn't it?

Andrew




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