Suppress instrumentation of PGO counter accesses, which is unnecessary
and costly. Also suppress accesses to other compiler inserted variables
starting with "__llvm". This is a slightly expanded variant of what is
done for tsan in shouldInstrumentReadWriteFromAddress.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Instrumentation/MemProfiler.cpp | ||
---|---|---|
649 | This changes the semantics from the previous version to only insert a load to the shadow memory if the function is instrumented. Is this expected? The insertDynamicShadowAtFunctionEntry function unconditionally returns true. Would it be simpler to return early and then call it? if (ToInstrument.empty()) { LLVM_DEBUG(dbgs() << "MEMPROF done instrumenting: " << FunctionModified << " " << F << "\n"); return FunctionModified; } FunctionModified = insertDynamicShadowAtFunctionEntry(F); | |
llvm/test/Instrumentation/HeapProfiler/skip-compiler-inserted.ll | ||
5 | I think this test will still pass if the memprof pass didn't run at all since there aren't any interesting loads/stores which we do instrument. Can you extend it to add another memory op which is instrumented by the pass? |
llvm/lib/Transforms/Instrumentation/MemProfiler.cpp | ||
---|---|---|
649 |
Yes - this change is mentioned at the end of the patch description. I realized we were inserting this unnecessarily when creating the new test case. However, with the change to the new test, this change is no longer tested here. I'm going to split it out into a different patch.
I had considered doing an early return, but then I wasn't sure I wanted to duplicate the debug logging - but I went ahead and made this change since it is a little clearer. Left the "|=" in case we ever change insertDynamicShadowAtFunctionEntry to do this conditionally. (To be moved to a new patch) |
This changes the semantics from the previous version to only insert a load to the shadow memory if the function is instrumented. Is this expected?
The insertDynamicShadowAtFunctionEntry function unconditionally returns true. Would it be simpler to return early and then call it?