[PATCH] D81716: Extend InlineFeatureAnalysis to more extract generic code features

[Tarindu Jayatilaka via Phabricator via llvm-commits]

tarinduj added a comment.

In D81716#2094270 <https://reviews.llvm.org/D81716#2094270>, @jdoerfert wrote:

> In D81716#2094081 <https://reviews.llvm.org/D81716#2094081>, @mtrofin wrote:
>
> > > 
> > > 
> > >> As a first step, if the planned new features would add space or computational overhead, could the work requiring the extra features have its own analysis and consume both analysis results? As we have examples of more such analyses and understand the usecases and performance tradeoffs, we can very easily refactor / rename.
> > > 
> > > While we can have more analysis if we want, I somehow doubt that will make it better. I was envisioning a lazy approach in which the analysis will not do anything until instructed to. Users can "ask" for what they want while reuse is still possible and code is kept at a single place. As an example, if users ask to `findCFGstructureFeatures` they will not get any instruction level results. Querying those could assert w/o extra cost. I don't see why this would cost us extra and I would prefer it very much over a multitude of passes. WDYT?
> >
> > IIUC, that means the one analysis memoizes results. I'm speculating invalidation would be total - i.e. even if only some results were needed (and, thus, computed), invalidation clears everything. Getting results would be semantically equivalent to having many analyses. Invalidating would be semantically equivalent to going piecemeal through the analyses that should be cleared and doing that. I'm not sure if that'd be always desirable, I suppose we'll learn when we hit a specific problem.
> >
> > How about this:
> >
> > - we rename InlineFeaturesAnalysis to FunctionFeaturesAnalysis (just because "Code" is too general - do we use that term elsewhere in LLVM?)
>
>
> I think that is fine. @tarinduj, WDYT?


Yeah, looks good.

> 
> 
>> - as long as the features are trivially computable , let's just eagerly compute them
> 
> Sure.
> 
>> - if this causes perf/space problems, or when we hit more complicated features, we figure out at that point what the best course of action may be.
> 
> Sounds good to me.
> 
> In D81716#2094112 <https://reviews.llvm.org/D81716#2094112>, @arsenm wrote:
> 
>> Is there a better name than features? I initially read this as having to do with subtarget features.
> 
> 
> Hm, properties?

So FunctionPropertiesAnalysis?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81716/new/

https://reviews.llvm.org/D81716