[PATCH] D121694: [clang][dataflow] Allow disabling built-in transfer functions for CFG terminators

Tue Mar 15 09:11:56 PDT 2022

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