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


> 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


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