This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: FDO usability: pid handling
On Tue, Apr 19, 2011 at 4:30 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On Tue, Apr 19, 2011 at 3:57 PM, Jan Hubicka <hubicka@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
>