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