This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Removal of gotos from cfg based ir
- From: Jan Hubicka <jh at suse dot cz>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, Jan Hubicka <jh at suse dot cz>,Jan Hubicka <hubicka at ucw dot cz>, Jason Merrill <jason at redhat dot com>,Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>,Diego Novillo <dnovillo at redhat dot com>,gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 17 Nov 2003 17:06:47 +0100
- Subject: Re: [tree-ssa] Removal of gotos from cfg based ir
- References: <200311150016.hAF0GXi6000905@speedy.slc.redhat.com> <1069082183.24623.81.camel@p4>
> On Fri, 2003-11-14 at 19:16, law@redhat.com wrote:
> > In message <1068848004.5920.23.camel@p4>, Andrew MacLeod writes:
> > >I would suggest that maybe you could put the execution counts right in
> > >the GOTO_EXPR's... oh, we NULL out the fallthru ones now don't we. hmm.
> > >why do we do that again?
> > Because if you leave them in, you get a 40% increase in the number of
> > jumps created when you translate from trees into rtl.
> >
> That seems silly. If you have a COND_EXPR and one of the GOTO's in the
> branch of the COND_EXPR is a GOTO to the next label, it seems like a
> pretty simple and obvious thing to not issue that goto. \
It is not easy when you do expansion of one node at time, as we do right
now. My CFG based expansion code is capable of that easilly.
>
> I was presuming we could be a little more intelligent about that so we
> could be consistent in a COND_EXPR. I would think it would be far better
> to leave the GOTO's instead of NULLS, otherwise things like loop
> replication and such are going to be back to having to deal with extra
> code because we sometimes have fallthru's in COND_EXPRs instead of
> something more natural.
What do you want to do after the cfg_remove-useless_stmts?
At the moment all optimizations happen before. THe only think I am
concerned about is that we un-gimplify the body by expansion and thus
when we decide to inline it later, we have to re-gimplify that is messy.
Honza
>
>
> > >the attraction of the notes concept is that it is optional. If the note
> > >isnt there, you dont have the information, so you dont use it. If you
> > >are going to make up the information in the absence of notes, then you
> > >are promoting the information from optional to necessary, its just that
> > >you have to make up the values before proceeding, so notes kind of fall
> > >apart there. PLus, in rtl there were lots of kinds of note, so you had
> > >to hunt to see if there were there, etc etc. I didnt like notes much
> > >either :-)
> > Notes suck. Both the kind attached to insns and the kind which appear
> > between insns. We've got the same fundamental problem with annoatations
> > right now that we're going to have to solve one day.
> >
> Most things we do in annotations ought to be directly in a node. Ive
> moved one or 2 things up into nodes from anoations, but we need to do it
> wholesale (and very carefuly !!!to avoid more memory explsoions :-) I
> would envision doing this when we atttempt to resolve some of our tree
> memory issues which would probably involve some restructuring anyway.
>
> Andrew