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:49 PM, Jan Hubicka <hubicka@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
>> >
>