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 17:00, Jan Hubicka wrote:
> > On Fri, 2003-11-14 at 16:38, Jan Hubicka wrote:
> > > > On Fri, 2003-11-14 at 15:51, Jan Hubicka wrote:

> > The bottom line is you want to do this in order to pass control flow
> > specific information  from one IL to another, and you think that
> > maintaining the same CFG across different ILs is a better solution than
> > annotating the exisiting IL with the information and building a new CFG
> > when the translation is done.
> > 
> > correct?
> 
> Yes, this is nice formulation.
> I don't see why we do need multiple mechanizms to represent information
> that is used only by CFG aware optimizers.  Inventing the annotation
> mechanizm is kind of code duplication too and it is very dificult to
> keep it up to date (as CFG itself is, but we has to do anyway), so it
> would be very short lived anyway.
> 

Every edge in the CFG is also represented by a stmt targetting a label
correct? so if the IL has a one-to-one correspondence of stmts to edges
in the CFG, it seems that there should be a location where the profile
information can be placed which is not the same as a note/etc. 

In the IL today, we have a GOTO_EXPR for every place we can have an edge
in the IL don't we?  (even for abnormal edges if we add the concept of
the TRAP_EXPR hanging off a stmt node).

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? 

> On RTL we used to represent profile by notes but it never worked very
> well (in fact we never managed to use that information).  My experience
> with any unrelated anotations on instruction stream is very bad.
> Perhaps it can be done somehow in significantly better way, but RTL
> scheme of REG_EQUIV/LOOP/SCOPE and similar notes has ever brought us
> headaches.
>
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 :-)

Andrew



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