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

[Chandler Carruth via llvm-dev]

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?


>
>> 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.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160418/c82b4170/attachment.html>