[PATCH] D56470: [NewPM] Second attempt at porting ASan

[Philip Pfaffe via Phabricator via llvm-commits]

philip.pfaffe added a comment.

I ran a benchmark using asan on a synthetic testcase made up of 10k functions and 10k globals, and it's clearly visible that GlobalsMD causes the performance problem. This is because during initialization it looks at all the globals registered in `llvm.asan.globals`, which is used to mark the globals coming from the frontend which are supposed to be instrumented. The function pass, however, doesn't use most of this, and accesses GlobalsMD only within `AddressSanitizer::GlobalIsLinkerInitialized` to check whether a global is dynamically initialized. This means we can fix this in two ways:

1. Change how the frontend marks globals, e.g. by attaching metadata directly to them instead of making the llvm.asan.globals list. This is the cleanest solution but it's quite invasive, and requires involving the sanitizer people to get them on board.
2. Make a module-level analysis that unpacks the global list.

You've done a lot of #2 already, and so it seems to be the easiest path forward. However, your solution needs a couple improvements:

- Your analysis does way too much. It should be a metadata analysis //only//.
- You need to handle invalidation, in the sense that your analysis is never invalidated.
- `FIXME` all the things, to make clear it should be replaced with direct metadata as in #1
- Use a hook to insert a require wrapper into the last module pass manager EP before the function pass manager containing asan is ran.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56470