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

[Xinliang David Li via llvm-dev]

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

> On Mon, Apr 18, 2016 at 5:36 PM Xinliang David Li <davidxl at google.com>
> wrote:
>
>> 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?
>>
>
> There is no invalidation of an immutable analysis pass in the old pass
> manager. So if you cache something, and it is changed, it won't really get
> updated unless you have a way to guarantee that every thing that updates
> the information *always* invalidates your cache (such as the ValueHandle
> machinery). But that style of cache invalidation often causes as many
> problems as it solves because it is very expensive.
>

I checked the existing immutable passes briefly:

1) TTI and TLI look like true immutable passes -- information gets created
during initialization and do not change
2) scope-based AA and type-based AA seem to be stateless, so they are ok.
Basic AA has cache, but it is not an immutable pass.
3) assumptionCacheTracker uses cache (as the name implies), and it requires
update
4) CFL AA -- has caching
5) MachineBranchProbabilityInfo -- it does not maintain any state  of its
own -- but queries MBB.


>
> As a concrete example, if you want to walk the call graph to compute
> transitive profile information on call graph edges,
>

What is your definition of 'transitive profile information'?



> you'll have no way to update this when the call graph changes other than
> to always recompute it when queried.
>

Not sure about this until we know the definition of 'transitive profile
info'.



>
>
>>
>>
>>
>>> 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.
>>
>
> The above only applies to things that change (function counts, etc).
> Genuinely immutable stuff is fine here.
>
> However, there is another problem -- even if it won't be changed while the
> optimizer is running, immutable analysis run before *all* transform passes,
> including any pass that reads profile data and writes it into the IR. =/
>


IIUC, Immutable analysis does not actually run?  Or for a truly immutable
pass, we can consider its 'run' is during its construction/initialization.
However for any other immutable pass,  it can certainly run *after* some
transformation passes as long as it is before any transformations that
depend on it. For instance, MachineBranchProbabillityInfo does not exist
until after MachineFunction is created, which is after many transformation
passes (which also need to update profile meta data which MBPI depends
on).  CFL AA is also created on demand, so its run is after transformation
passes that do not need to query AA.   AssumptionCacheTracker is likewise.

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