> On Tue, Apr 19, 2011 at 4:49 PM, Jan Hubicka <hubi...@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 > >> > > >
