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

Mon Apr 18 17:09:19 PDT 2016

Sent from my Verizon Wireless 4G LTE DROID
On Apr 18, 2016 6:48 PM, Xinliang David Li <xinliangli at gmail.com<mailto:xinliangli at gmail.com>> wrote:
>
>
>
> On Mon, Apr 18, 2016 at 4:43 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>>
>> ________________________________
>>>
>>> From: "Xinliang David Li" <davidxl at google.com<mailto:davidxl at google.com>>
>>> To: "Chandler Carruth" <chandlerc at gmail.com<mailto:chandlerc at gmail.com>>
>>> Cc: "Hal Finkel" <hfinkel at anl.gov<mailto:hfinkel at anl.gov>>, "via llvm-dev" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>, "Mehdi Amini" <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>>
>>> Sent: Monday, April 18, 2016 6:38:32 PM
>>> Subject: Re: [llvm-dev] Move InlineCost.cpp<http://InlineCost.cpp> out of Analysis?
>>>
>>>
>>>
>>> On Mon, Apr 18, 2016 at 3:59 PM, Chandler Carruth <chandlerc at gmail.com<mailto:chandlerc at gmail.com>> wrote:
>>>>
>>>> On Mon, Apr 18, 2016 at 3:45 PM Xinliang David Li <davidxl at google.com<mailto:davidxl at google.com>> wrote:
>>>>>
>>>>> On Mon, Apr 18, 2016 at 3:00 PM, Chandler Carruth <chandlerc at gmail.com<mailto:chandlerc at gmail.com>> wrote:
>>>>>>
>>>>>> On Mon, Apr 18, 2016 at 2:48 PM Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ________________________________
>>>>>>>>
>>>>>>>> From: "Xinliang David Li" <davidxl at google.com<mailto:davidxl at google.com>>
>>>>>>>>
>>>>>>>> On Mon, Apr 18, 2016 at 2:33 PM, Mehdi Amini <mehdi.amini at apple.com<mailto: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.

Ah, good point.

-Hal

>
>>
>> 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<mailto: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/20160419/770d168b/attachment.html>