[llvm-dev] Move InlineCost.cpp out of Analysis?

Mon Apr 18 16:48:28 PDT 2016

On Mon, Apr 18, 2016 at 4:43 PM, Hal Finkel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> ------------------------------
>
> *From: *"Xinliang David Li" <davidxl at google.com>
> *To: *"Chandler Carruth" <chandlerc at gmail.com>
> *Cc: *"Hal Finkel" <hfinkel at anl.gov>, "via llvm-dev" <
> llvm-dev at lists.llvm.org>, "Mehdi Amini" <mehdi.amini at apple.com>
> *Sent: *Monday, April 18, 2016 6:38:32 PM
> *Subject: *Re: [llvm-dev] Move InlineCost.cpp out of Analysis?
>
>
>
> On Mon, Apr 18, 2016 at 3:59 PM, Chandler Carruth <chandlerc at gmail.com>
> wrote:
>
>> On Mon, Apr 18, 2016 at 3:45 PM Xinliang David Li <davidxl at google.com>
>> wrote:
>>
>>> On Mon, Apr 18, 2016 at 3:00 PM, Chandler Carruth <chandlerc at gmail.com>
>>> wrote:
>>>
>>>> On Mon, Apr 18, 2016 at 2:48 PM Hal Finkel <hfinkel at anl.gov> wrote:
>>>>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> *From: *"Xinliang David Li" <davidxl at google.com>
>>>>>
>>>>> On Mon, Apr 18, 2016 at 2:33 PM, Mehdi Amini <mehdi.amini at apple.com>
>>>>> wrote:
>>>>>>
>>>>>> In the current case at stake: the issue is that we can't make the
>>>>>> Analysis library using anything from the ProfileData library. Conceptually
>>>>>> there is a problem IMO.
>>>>>>
>>>>>
>>>>>
>>>>> Yes -- this is a very good point.
>>>>>
>>>>> Independent of anything else, +1.
>>>>>
>>>>
>>>> The design of ProfileData and reading profile information in the entire
>>>> middle end had a really fundamental invariant that folks seem to have lost
>>>> track of:
>>>>
>>>
>>> Not sure about what you mean by 'lost track of'.
>>>
>>
>> I mean that we used to hold to these invariants but I think recently the
>> code has started to not follow them as closely.
>>
>>
>>>
>>>> a) There is exactly *one* way to get at profile information from
>>>> general analyses and transforms: a dedicated analysis pass that manages
>>>> access to the profile info.
>>>>
>>>
>>>
>>> This is not the case as of today.
>>>
>>
>> Again, my whole comment was that these are no longer being correctly
>> followed.
>>
>>
>>>   BPI is a dedicated analysis pass to manage branch probability profile
>>> information, but this pass is only used in limited situations (e.g, for
>>> BFI, profile update in jump-threading etc) -- using it it requires more
>>> memory as well as incremental update interfaces.  Many transformation
>>> passes simply skip it and directly access the meta data in IR.
>>>
>>
>> Can you be more specific?
>>
>> BPI and BFI are used in *many* places, and on an initial inspection
>> almost everywhere that accesses MD_prof directly appears to do so in order
>> to *set* or *update* the profile information without doing detailed
>> analysis on it. Which seems fine with my outline of the invariants?
>>
>>
>
> See my reply to Hal.
>
>
>>
>>>> Now, the original design only accounted for profile information
>>>> *within* a function body, clearly it needs to be extended to support
>>>> intraprocedural information.
>>>>
>>>
>>>
>>> Not sure what you mean.  Profile data in general does not extend to IPA
>>> (we will reopen discussion on that soon), but profile summary is
>>> 'invariant'/readonly data, which should be available to IPA already.
>>>
>>
>> I don't know what you mean by "invariant" or readonly data here. I think
>> that whether or not the profile information is mutated shouldn't influence
>> the design invariants I described above.
>>
>
>
> I do not disagree with this. What I was saying is that the information can
> be made available to IPA in some form due to its readonly nature.
>
> Can you please clarify what information you view as readonly?
>

I actually it is immutable -- i.e, no need for update.

> I can understand function entry counts being readonly,
>

Function entry counts are actually mutable -- inlining, cloning etc will
need to update the entry count of the callee instance.

> but branch information within a function seems mutable. Is this also what
> you're talking about?
>

Basically  profile summary is program level information which won't be
modified after it is created/read .

David

>
>  -Hal
>
>
> David
>
>
>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160418/76270bfd/attachment-0001.html>