This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: FDO usability: pid handling
Discard this version of the patch. I have not updated source properly
and the build/test was invalid.
David
On Wed, Apr 20, 2011 at 11:22 AM, Xinliang David Li <davidxl@google.com> wrote:
> Here is the revised patch. Basic FDO testing went fine. I still saw
> the ipa-inline assertion in SPEC FDO. Will run it when the regression
> is fixed.
>
> Thanks,
>
> David
>
> On Tue, Apr 19, 2011 at 5:33 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>> 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.
>>
>> Sure, that is why I suggested cgraph->uid. ?That one is kept dense and it also
>> tracks cgraph node creation order. Unlike pid it counts also functions w/o
>> bodies.
>>> > 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.
>>
>> Well, that is the case of all of them (passes can create function bodies that
>> can make funcdef_no also diverge). ?This is the case of couple passes already,
>> especially OMP lowering and friends.
>>
>>> 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;
>>
>> It depends on optimization, too. ?This is why we actually have cgraph->order
>> that is used for -fno-toplevel-reorder and is similar to funcdef_no, but
>> assigned at finalization time.
>>
>>> 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);
>>
>> You get the cgraph uids in the dumps already.
>>> ? ?b) it can be very useful in bug triaging via binary search by
>>> specifying ranges of function ids (to enable optimizations etc).
>>
>> But as you wish, we can process with fundef_no first and then discuss
>> removal of that field later.
>>
>> Honza
>>>
>>> Thanks,
>>>
>>> David
>>>
>>>
>>> >
>>> > Honza
>>> >>
>>> >> David
>>> >>
>>> >>
>>> >>
>>> >> >
>>> >> > Honza
>>> >> >
>>> >
>>
>