Re: FDO usability: pid handling

[Jan Hubicka <hubicka at ucw dot cz>]

> On Tue, Apr 19, 2011 at 4:49 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
> >> Actually, among all the choices, funcdef_no is probably the most dense
> >> one -- it is for function decl with definition only. ?In LIPO, the
> >
> > Yes, funddef_no is densiest, but we don't really need great density here
> > (in many other places we index arrays by cgraph_uid - it is intended for
> > that purpose and we pay some attention to recycle unused nodes).
> >
> 
> That does not mean it is right to use sparse ids:)  DECL_UID will be
> the worst amongst them.

Sure, that is why I suggested cgraph->uid.  That one is kept dense and it also
tracks cgraph node creation order. Unlike pid it counts also functions w/o
bodies.
> > We only care to avoid divergence in the indexes in between instrumentation
> > and feedback compilation. ?With the IPA pass organizatoin the compiler doesn't
> > really diverge until the profile pass, so it seems to me that all should be safe.
> 
> When I said 'fragile' -- I meant it depends on the optimization pass
> phase ordering which can change in the future.

Well, that is the case of all of them (passes can create function bodies that
can make funcdef_no also diverge).  This is the case of couple passes already,
especially OMP lowering and friends.

> Ok, I will throw away pid and use funcdef_no for now.  For future
> replacement for the function ids, please consider the following
> desired properties:
> 
> 1) The id sequence does not depend on optimization passes -- only
> depend on source/parsing order;

It depends on optimization, too.  This is why we actually have cgraph->order
that is used for -fno-toplevel-reorder and is similar to funcdef_no, but
assigned at finalization time.

> 2) It is dense and sequential for defined functions
>    a) it has proven to be very useful to use nice looking, sequential
> ids in triaging coverage mismatch related problems (the tree dump
> should also show the function id);

You get the cgraph uids in the dumps already.
>    b) it can be very useful in bug triaging via binary search by
> specifying ranges of function ids (to enable optimizations etc).

But as you wish, we can process with fundef_no first and then discuss
removal of that field later.

Honza
> 
> Thanks,
> 
> David
> 
> 
> >
> > Honza
> >>
> >> David
> >>
> >>
> >>
> >> >
> >> > Honza
> >> >
> >