> 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). 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. 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. Honza > > David > > > > > > > Honza > >
