On Tue, Apr 19, 2011 at 4:30 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> On Tue, Apr 19, 2011 at 3:57 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> >> So between hashtab and VEC, which one do you prefer? Either one is fine >> >> with me. >> > >> > I would go with VEC. While the array will have holes, there are not many >> > since >> > the ids are originally assigned sequentially. >> > >> > Actually given that we do IPA pass now, I think you can just remove >> > cgraph->pid >> > field and replace it by cgraph->uid. The original issue was that profiling >> > made cgraph->uid diverge in between compilation and profling time becuase >> > it >> > affected things like early inlining. This is not true anymore, so >> > cgraph->uid >> > should work well now. >> >> Why not using struct function's funcdef_no? > > Well, we have DECL_UID, cgraph_node->uid and struct function funcdef_no. I > think funcdef_no is least used and probably could be dropped in favour of the > other two. It seems to be used only in order to generate unique labels for > functions, > that should be easilly replaceable by DECL_UID. > > DECL_UID and cgraph_node->uid will probably have to stay since they drive > quite > few datastructures.
Actually, among all the choices, funcdef_no is probably the most dense one -- it is for function decl with definition only. In LIPO, the 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. David > > Honza >
