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

[Xinliang David Li via llvm-dev]

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

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

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