[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