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. funccdef_no is pretty close to the current cgraph_node->pid given their similarity in creation order, so it will be the safest replacement for pid (for now). > If we will need density later, we can have local mapping for that. > >> global func id is created based on module_id and funcdef_no. IMO, >> using DECL_UID or cgraph_node->uid can make the implementation >> fragile. > > 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. > > What I am shooting for is to eliminate useless data in our core datastructures > to reduce memory usage and LTO streaming. Killing funcdef_no is obviously > quite > low hanging fruit here. struct_function is quite bad in this respect as it has > been a kitchen sink for various data over a decades. > > But we might pretty well use it here for time being and I will eliminate it > together > with the few other uses in the compiler. 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; 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); b) it can be very useful in bug triaging via binary search by specifying ranges of function ids (to enable optimizations etc). Thanks, David > > Honza >> >> David >> >> >> >> > >> > Honza >> > >
