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

[Philip Pfaffe via Phabricator via llvm-commits]

philip.pfaffe added a comment.



> Sorry for the delayed response. So the main problem is that `AddressSantizer` needs to perform some initialization involving reading stuff from global metadata and getting some target specific information. More specifically, just these 6 things which are all initialized in `doInitialization`:
> 
>   GlobalsMD.init(M);
>   C = &(M.getContext());
>   LongSize = M.getDataLayout().getPointerSizeInBits();
>   IntptrTy = Type::getIntNTy(*C, LongSize);
>   TargetTriple = Triple(M.getTargetTriple());
>   Mapping = getShadowMapping(TargetTriple, LongSize, CompileKernel);
>    

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.

> To me it seems that there just needs to be an equivalent `doInitialization` that accepts modules for function passes in the new PM, but it seems that given the way runs are performed in the new PM, there's no inherit way to access the "parent" IRUnit of a given IRUnit. Was this what you were suggesting with the `function outside of the pass pipeline` @philip.pfaffe ? An alternative idea that @tamur suggested was putting the global metadata and other initialized data into a lazy data structure that can be accessed by the `AddressSanitizers`.

There can't be a `doInitialization` in the new pass manager. It really doesn't fit the design. There can be multiple instances of a pass, both in the same pass manager or in different managers. Who does the initialization?

The free function thing I suggested was to do the initialization bits that modify the module. Function passes currently are allowed to insert global variables, MD, and other function declarations, but no function bodies. If asan doesn't need that, great! Doing the rest of the initialization lazily works, though! A thing to keep in mind though is that multiple instances of the pass still initialize multiple times, so it should be both cheap(-ish) and reentrant (in the sense that it shouldn't add e.g. functions twice).

> Would having this as a ModulePass also make that much of an impact in instrumentation speed? From what I could determine, with AddressSanitizer as a FunctionPass, control of this is delegated to the FunctionPassManager whose 'runOnModule` method just iterates through every function in the module, and it seems that the only actions done between the FunctionPass's `doInitialization` and FunctionPassManager's `runOnModule` is counting the size of the module and initializing some analyses, but I could also be overlooking something big here.

Function passes are pipelined //per function//. That means that for a given function you first run simplification, optimization, and then the sanitizer without touching another function. So everything is nice and local. With a module pass you loose all that locality.


Repository:
  rL LLVM

https://reviews.llvm.org/D54337