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? David > > Honza >> >> Thanks, >> >> David >> >> On Tue, Apr 19, 2011 at 3:39 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> >> >> >> Why is VEC any better in terms of density ? Are you suggesting using a >> >> hash table? >> > It is not any better, but we usually use VEC for variably sized arrays like >> > this one. Not that I would be big fan of its API, but at least it fives >> > bounds checking that would catch bugs like one you are fixing more >> > reliably. >> > >> > Honza >> >> >> >> >> >> , making init_pid_map to allocate it cleared and add also >> >> > test that VEC_index (pid_map, pid) is not NULL in addition to the bound >> >> > check >> >> > above. >> >> > >> >> > Also we ought to free pids once the IPA profiling pass is done. I.e. at >> >> > the end of tree_profling >> >> > function. >> >> >> >> Yes. >> >> >> >> Thanks, >> >> >> >> David >> >> >> >> > >> >> > Honza >> >> > >> > >
