[PATCH] D121797: [clang][dataflow] Add modeling of Chromium's CHECK functionality

Gábor Horváth via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Mar 16 15:23:27 PDT 2022


xazax.hun added inline comments.


================
Comment at: clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp:122
+  void transfer(const Stmt *S, NoopLattice &, Environment &Env) {
+    M.transfer(S, Env);
+  }
----------------
ymandel wrote:
> xazax.hun wrote:
> > I wonder whether the models should actually be called by the framework at some point. 
> > E.g. imagine the following scenario:
> > ```
> > void f()
> > {
> >     std::optional<int> o(5);
> >     if (o)
> >     {
> >         // dead code here;
> >     }
> > }
> > ```
> > 
> > In an ideal case, an analysis could use the `std::optional` modeling to realize that the code in the `if` statement is dead and use this fact to improve its precision. Explicitly request the modeling in the transfer function works OK when we only have a couple things to model. But it might not scale in the future. When we model dozens of standard types and functions we would not want all the analysis clients to invoke all the transfers for all the models individually. 
> Agreed. It seems similar the problems that motivated DLLs back in the day. there's clearly a lot to be worked out here in terms of how best to support composition. It's probably worth a RFC or somesuch to discuss in more depth.
Having an RFC and some deeper discussions would be great. I also wonder whether modeling arbitrary `Stmt`s is the right approach. The peculiarities of the language should probably be modelled by the framework itself without any extensions. Maybe we only want the modeling of certain function calls to be customizable?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121797



More information about the cfe-commits mailing list