[PATCH] D82270: Added a Printer to the FunctionPropertiesAnalysis

Johannes Doerfert via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 24 09:09:41 PDT 2020


jdoerfert added a comment.

In D82270#2110007 <https://reviews.llvm.org/D82270#2110007>, @mtrofin wrote:

> In D82270#2109923 <https://reviews.llvm.org/D82270#2109923>, @jdoerfert wrote:
>
> > In D82270#2106860 <https://reviews.llvm.org/D82270#2106860>, @mtrofin wrote:
> >
> > > What's the value of having the result type have the analyze method? Is there a scenario where we want to get the result and then re-analyze it?
> >
> >
> > In the new-PM if you preserve the analysis it doesn't need to be recomputed, I thought. Or maybe I misunderstand your question. Could you elaborate?
> >
> > [EDIT: Do you mean the `...Info` struct? It is used by two passes, right?]
>
>
> What I mean was, why not let the computation happen in the Analysis::run, and the Info is basically an object not meant to be mutated. This is because the PM will call ::run to recompute, and we don't really have (or want to have) a scenario where we want someone to call Info::analyze() (unless I'm missing something)


Oh, I see. This is a common pattern, I think. Mostly because it allows the passes to be minimal wrappers. This is good as we might want to have an old-PM pass as well. Then you want the analyze in the info "for sure". Even without an old-PM pass, this way allows old-PM cgscc passes to create the info object and populate it, something that doesn't work in the old-PM through the pass mechanism.

Is there a strong reason or is it more a design preference?


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

https://reviews.llvm.org/D82270





More information about the llvm-commits mailing list