Move InlineCost.cpp out of Analysis?

Sent from my Verizon Wireless 4G LTE DROID
On Apr 18, 2016 6:48 PM, Xinliang David Li <xinliangli@gmail.com> wrote:
>
>
>
> On Mon, Apr 18, 2016 at 4:43 PM, Hal Finkel via llvm-dev <llvm-dev@lists.llvm.org> wrote:
>>
>>
>> ________________________________
>>>
>>> From: “Xinliang David Li” <davidxl@google.com>
>>> To: “Chandler Carruth” <chandlerc@gmail.com>
>>> Cc: “Hal Finkel” <hfinkel@anl.gov>, “via llvm-dev” <llvm-dev@lists.llvm.org>, “Mehdi Amini” <mehdi.amini@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@gmail.com> wrote:
>>>>
>>>> On Mon, Apr 18, 2016 at 3:45 PM Xinliang David Li <davidxl@google.com> wrote:
>>>>>
>>>>> On Mon, Apr 18, 2016 at 3:00 PM, Chandler Carruth <chandlerc@gmail.com> wrote:
>>>>>>
>>>>>> On Mon, Apr 18, 2016 at 2:48 PM Hal Finkel <hfinkel@anl.gov> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ________________________________
>>>>>>>>
>>>>>>>> From: “Xinliang David Li” <davidxl@google.com>
>>>>>>>>
>>>>>>>> On Mon, Apr 18, 2016 at 2:33 PM, Mehdi Amini <mehdi.amini@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@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>