[PATCH] D54337: [ASan] Make AddressSanitizer a ModulePass

Fedor Sergeev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 3 13:06:49 PST 2018


fedor.sergeev added a comment.

In D54337#1303405 <https://reviews.llvm.org/D54337#1303405>, @leonardchan wrote:

> In D54337#1300858 <https://reviews.llvm.org/D54337#1300858>, @philip.pfaffe wrote:
>
> > If asan doesn't modify the module for this ('this' meaning the Mapping and the GlobalsMD here), than this is an excellent candidate for an analysis.
>
>
> When you say analysis, do you mean like the `TargetLibraryInfoWrapperPass` that AddressSanitizer is dependent on? Not sure what the difference between passes and analyses are, but if the purpose of `TargetLibraryInfoWrapperPass` is to just pass a `TargetLibraryInfo` to AddressSantizer, then it seems a new WrapperPass could similarly be made for this initialized data as a custom class made specifically for ASan.


Passes are transformations that are allowed (and actually expected) to mutate the IR.
Analyses are (well, in NewPM) not passes, they are run over IR and store their "analytics" as the analysis result into the Analysis Manager.
Passes can query Analysis Manager and get the results that are either cached or calculated on demand.

Analysis can be any information which is not an IR itself. TargetLibraryInfo, DominatorTree, GlobalsMetadata... whatever.
The only problem that you might find when using your custom analysis from the pass will be similar to the current dichotomy of module & function ASan.
You can not *run* module analysis from within a function pass. It can only be run on a module level.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D54337





More information about the llvm-commits mailing list