[PATCH] D100912: [docs][NewPM] Add section on analyses

Arthur Eubanks via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 20 20:26:57 PDT 2021


aeubanks added inline comments.


================
Comment at: llvm/docs/NewPassManager.rst:199
+There are two ways to deal with potentially invalid analysis results. One is
+to simply force clear the results. This should generally only be used when
+the IR that the result is keyed on becomes invalid. For example, a function
----------------
mtrofin wrote:
> I'd stress here that this must be used when deleting the IR, explicitly, by the pass - and show the code example. I'd also stress that if passes don't do that, the risk is that the same key (==obj pointer) may be used for newly allocated IR and the stale cached value may appear valid when it's not.
Will do, although it's only an issue if a pass deletes then adds functions.


================
Comment at: llvm/docs/NewPassManager.rst:239
+
+An analysis should implement ``invalidate()`` like below, at least for simple
+cases:
----------------
mtrofin wrote:
> aeubanks wrote:
> > mtrofin wrote:
> > > but for simple cases that's not necessary, the default impl does that, no?
> > There's no default implementation?
> > Each analysis's `Result` type needs to implement `invalidate()`. Although that does bring up a good point that it's specifically the result that implements it, not the analysis interface. Will clarify.
> See PassManagerInternal.h:172 - there's a wrapper to the analysis result concept. Result::invalidate doesn't need to be implemented unless it does something non-trivial.
Oh I didn't know that, thanks for the pointer! Will definitely put that in.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100912



More information about the llvm-commits mailing list