This is an archive of the discontinued LLVM Phabricator instance.

[memprof] Don't instrument PGO and other compiler inserted variables
ClosedPublic

Authored by tejohnson on Apr 29 2022, 2:58 PM.

Details

Summary

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.

Diff Detail

Event Timeline

tejohnson created this revision.Apr 29 2022, 2:58 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 29 2022, 2:58 PM
tejohnson requested review of this revision.Apr 29 2022, 2:58 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 29 2022, 2:58 PM
snehasish added inline comments.Apr 29 2022, 5:35 PM
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?

tejohnson marked an inline comment as done.May 2 2022, 11:18 AM
tejohnson added inline comments.
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?

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.

The insertDynamicShadowAtFunctionEntry function unconditionally returns true. Would it be simpler to return early and then call it?

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)

tejohnson updated this revision to Diff 426464.May 2 2022, 11:18 AM

Address comments. Remove now unrelated change.

tejohnson edited the summary of this revision. (Show Details)May 2 2022, 11:19 AM
This revision is now accepted and ready to land.May 2 2022, 11:22 AM
This revision was landed with ongoing or failed builds.May 2 2022, 12:18 PM
This revision was automatically updated to reflect the committed changes.