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

[Chandler Carruth via llvm-dev]

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:

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.

b) There is exactly *one* way for this analysis to compute this information
from an *external* profile source: profile metadata attached to the IR.

c) There could be many external profile sources, but all of them should be
read and then translated into metadata annotations on the IR so that
serialization / deserialization preserve them in a common format and we can
reason about how they work.


This layering is why it is only a transform that accesses ProfileData -- it
is responsible for annotating the IR and nothing else. Then the analysis
uses these annotations and never reads the data directly.

I think this is a really important separation of concerns as it ensures
that we don't get an explosion of different analyses supporting various
different subsets of profile sources.


Now, the original design only accounted for profile information *within* a
function body, clearly it needs to be extended to support intraprocedural
information. But I would still expect that to follow a similar layering
where we first read the data into IR annotations, then have an analysis
pass (this time a module analysis pass in all likelihood) that brokers
access to these annotations through an API that can do intelligent things
like synthesizing it from the "cold" attribute or whatever when missing.

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