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: [tree-ssa] Removal of gotos from cfg based ir


Hello,

> > with cfg, ordinary gotos (not computed, local) do not carry any useful
> > information and their presence complicates things (e.g. having to handle
> > several types of edges, having to create new basic blocks sometimes when
> > redirecting edges, and also having to remove superfluous gotos).
> >
> Well, I think the idea is sort of enticing from the point of view of
> flow manipulation.  But it's not very clear to me whether it buys us
> much.  Yes, when redirecting edges we don't have to insert a label and a
> goto.

and you may do it many times; this seems to me that it indeed saves some
garbage.

> But at some point we will have to do that.  So we're just
> delaying it.
>
> You say we don't have to handle several types of edges.  How do we tell
> if an edge needs a goto/label pair when we go out of the CFG?

Simply; if we see a fallthru edge that does not have a goto, we need to
add it.

> Could you give examples of your other points?  (creation of a basic
> block when redirecting edges

Consider a basic block that ends in statement causing an exception.  You
cannot redirect the outgoing fallthru edge without creating a new basic
block.

> and removal of superfluous gotos).

Whenever you do some cfg manipulation now, you must take care to update
fallthru flag and remove/insert requiered gotos.

> What exactly are the big savings in terms of infrastructure complexity?
> diffstat for the patch shows that you added more than twice the number
> of lines that you removed.

That is indeed quite possible; there is of course some over initial
overhead (to handle a new type of statement, etc).  For savings in
infrastructure complexity, consider functions that really manipulate
cfg, like edge redirection and edge splitting.

> > The same fact is used to represent conditional expressions in more
> > memory efficient fashion (the only useful information from COND_EXPR is
> > the condition, the rest is represented by cfg).
> >
> That needs to be expanded eventually.  Do you have numbers to prove your
> point?  I'd like to see a benefit/cost analysis for this change.
>
> I'm not opposed to the change, if you can show me tangible benefits to
> switching to this representation.  I'm having a hard time trying to find
> things we can do with this new representation that we cannot do with the
> existing one.

Of course they are equivalent; just there are less redundant information
and thus less things to update with my one.

> > To keep the things consistent, I have also massaged SWITCH_EXPRs to
> > work the same way; in
> > fact, it turned out to be natural to represent both of these
> > constructions by a single statement -- CF_EXPR; this made it possible
> > to
> > simplify some of the code that previously was done twice, once for
> > COND_EXPRs and once for SWITCH_EXPRs.
> > 
> Hmm, why is this change related to the GOTO_EXPR removal?  It seems
> orthogonal to me.

Kind of.  It was simpler to do it simultaneously, as it enables you
to really simplify the edge manipulation functions by making things more
consistent, but I it would be possible to split the patch.

> > We produce a bit fewer jumps than before; for example number of lines of
> > combine.c.01.rtl decreases from 158034 to 157474.
> > 
> Oh?  Why is that?  You just changed the way we represent jumps.  This is
> unexpected.

Because the cleanups we have now preserve some gotos they do not have
to.

Zdenek


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