A latent bug - use of BRANCH_EDGE on trees.

Steven Bosscher stevenb@suse.de
Mon Oct 25 10:30:00 GMT 2004


On Sunday 24 October 2004 21:54, Zdenek Dvorak wrote:
> Hello,
>
> > > > > yes, this indeed is a problem.  There are several solutions:
> > > > >
> > > > > 1) Let the caller pass the edge corresponding to the current
> > > > >    BRANCH_EDGE (switch_bb) to loopify
> > > > > 2) Let BRANCH_EDGE check ir_type and use EDGE_{TRUE,FALSE}_FLAG for
> > > > >    trees.
> > > > > 3) Let EDGE_FALSE_FLAG == EDGE_FALLTHRU
> > > > >
> > > > > I do not have any special preference here.
> > > >
> > > > Or
> > > >
> > > > 4. Do the following.
> > > >
> > > >   if (ir_type ())
> > > >     /* We are in trees.  */
> > > >     true_edge = ((EDGE_SUCC (switch_bb, 0)->flags & EDGE_TRUE_VALUE)
> > > > 		 ? EDGE_SUCC (switch_bb, 0)
> > > >
> > > > 		 : EDGE_SUCC (switch_bb, 1));
> > > >
> > > >   else
> > > >     /* We are in RTL.  */
> > > >     true_edge = BRANCH_EDGE (switch_bb);
> > > >
> > > >   loop_redirect_edge (true_edge, succ_bb);
> > > >
> > > > I guess!?
> > >
> > > yes, but in general it is preferred not to expose such IR dependencies
> > > directly in the high-level functions (i.e. the equivalent solution
> > > 2) is better).
> >
> > But it's really, really ugly that we would call ir_type() in
> > BRANCH_EDGE.  We just perhaps not use BRANCH_EDGE here in the
> > first place.
>
> I do not see what exactly would be that ugly about making BRANCH_EDGE
> work regardless of the ir type, but yes, 1) is also a solution :-)

There is nothing specifically ugly about IR independence in principle,
except that:
1) people expect BRANCH_EDGE to be cheap and you'd add a function
   call to it so it is needlessly expensive.
2) BRANCH_EDGE really doesn't have much of a meaning on trees, so
   making it work on trees just does not make sense.

Gr.
Steven




More information about the Gcc mailing list