A latent bug - use of BRANCH_EDGE on trees.

[Zdenek Dvorak]

Hello,

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

you really believe that this would make any measurable difference
in compile time???? Uhhh...

> 2) BRANCH_EDGE really doesn't have much of a meaning on trees, so
>    making it work on trees just does not make sense.

You may rename it to something more senseful (like EDGE_TRUE, or
whatever); in a sense what I find ugly is having both
BRANCH_EDGE/FALLTHRU_EDGE and extract_true_false_edges_from_block.

Zdenek