[PATCH] D85319: [analyzer] Get info from the LLVM IR for precision

Gabor Marton via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Aug 5 09:14:45 PDT 2020


martong marked 3 inline comments as done.
martong added inline comments.


================
Comment at: clang/include/clang/StaticAnalyzer/Core/IRContext.h:39-41
+  // Get the LLVM code for a function. We use the complete versions of the
+  // constructors and desctructors in this overload. Use the other overload to
+  // get the base object ctor/dtor.
----------------
whisperity wrote:
> Aren't documentation comments in LLVM `///`?
Yep, I forgot about that.


================
Comment at: clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:127
         PP(CI.getPreprocessor()), OutDir(outdir), Opts(std::move(opts)),
-        Plugins(plugins), Injector(injector), CTU(CI) {
+        Plugins(plugins), Injector(injector), CTU(CI), IRCtx(CG) {
     DigestAnalyzerOptions();
----------------
whisperity wrote:
> Where's this `CG` defined?
In `AnalysisConsumer.h`. And set in `FrontendActions.cpp` `AConsumer->setCodeGen(CGConsumer.get());`


================
Comment at: clang/lib/StaticAnalyzer/Frontend/FrontendActions.cpp:53-57
+    LLVMCtx = std::make_shared<llvm::LLVMContext>();
+    auto CGConsumer = BuildCodeGen(CI, *LLVMCtx, *CodeGenDiags);
+    AConsumer->setCodeGen(CGConsumer.get());
+    ASTConsumers.push_back(std::move(CGConsumer));
+  }
----------------
whisperity wrote:
> Isn't there a lifetime issue here? `LLVMCtx` is given as a raw reference to the `BuildCodeGen` and the shared pointer leaves scope at the end of the branch.
Nope, `LLVMCtx` is a member of `AnalysisAction`.


================
Comment at: clang/test/Analysis/ircontext.cpp:17-18
+  int l = 0;
+  foo(&l);
+  clang_analyzer_eval(g == 3); // expected-warning{{TRUE}}
+}
----------------
whisperity wrote:
> What are we testing here? Without the ability to read the pureness of `foo` from the IR, the knowledge about `g`'s value would be scrapped at the call? `foo` is defined in the current TU.
We test here that with no-inlining (i.e. always doing conservative evaluation) we do not invalidate the state after a call to a pure function.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85319



More information about the cfe-commits mailing list