ymandel added a comment. In D121694#3382683 <https://reviews.llvm.org/D121694#3382683>, @xazax.hun wrote:
> In D121694#3382587 <https://reviews.llvm.org/D121694#3382587>, @ymandel wrote: > >> In D121694#3382473 <https://reviews.llvm.org/D121694#3382473>, @xazax.hun >> wrote: >> >>> The change itself looks good. But out of curiosity, could you give me an >>> example when we do not want to use the builtin transfer functions? >> >> Sure! Pretty much any plain-vanilla dataflow analysis that sticks to its own >> lattice and doesn't care about the environment. The demo >> constant-propagation analyses are like this, but we have additional real >> analyses using the framework in this way. Examples include an analysis to >> detect raw pointers that could be unique pointers and one that detects >> missed opportunies to use `std::move`. > > Makes sense! Although, I wonder if we would want an alternative API where the > transfer function would not even get Env as an argument. So users could pick > the right class to derive from for their needs and the decision whether use > the built-in transfer functions would be compile time. That would make sense. We definitely don't want to stick w/ the current setup. But, we've been thinking that we can split out `Env` and its transfer functions as a standalone "model" that users can choose to compose with their own (more specialized) model. I'm planning to send a patch shortly with an initial API for "models" (basically, a virtual API corresponding to `DataflowAnalysis` as of now). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D121694/new/ https://reviews.llvm.org/D121694 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
