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

Xinliang David Li via llvm-dev llvm-dev at lists.llvm.org
Mon Apr 18 17:36:46 PDT 2016

On Mon, Apr 18, 2016 at 5:14 PM, Chandler Carruth <chandlerc at gmail.com>

> On Mon, Apr 18, 2016 at 4:38 PM Xinliang David Li <davidxl at google.com>
> wrote:
>>>>> 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.
> While it can be made available, it is very hard to make it available even
> in a readonly form in the current pass manager.
> You essentially have to avoid caching anything and make the API always
> re-examine the IR annotations in order to reflect changes to them. There
> are a few other "Immutable" analysis passes that abuse the legacy pass
> manager in this way.

Can you explain ? Why caching has to be avoided? What are these abuses?

> That seems fine as a temporary thing. I don't *think* this kind of
> information would pose a significant compile time cost to recompute on each
> query, but I've not looked at the nature of the IPA queries you would want
> to make.

Note that for profile summary, since it is at program level (thus identical
across modules), recomputing (re-reading from meta data) seems a waste --
though not to big as measured by Easwaran.

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

More information about the llvm-dev mailing list