[llvm-dev] Move InlineCost.cpp out of Analysis?
Chandler Carruth via llvm-dev
llvm-dev at lists.llvm.org
Mon Apr 18 15:59:18 PDT 2016
On Mon, Apr 18, 2016 at 3:45 PM Xinliang David Li <davidxl at google.com>
> On Mon, Apr 18, 2016 at 3:00 PM, Chandler Carruth <chandlerc at gmail.com>
>> 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>
>>>> 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
> 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
> 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...
More information about the llvm-dev