This is the mail archive of the 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, 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.  \

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.

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


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