This is an archive of the discontinued LLVM Phabricator instance.

[SanitizerBinaryMetadata] Treat constant globals and non-escaping addresses specially
ClosedPublic

Authored by melver on Feb 2 2023, 2:33 AM.

Details

Summary

For atomics metadata, we can make data race analysis more efficient by
entirely ignoring functions that include memory accesses but which only
access non-escaping (non-shared) and/or non-mutable memory. Such
functions will not be considered to be covered by "atomics" metadata,
resulting in the following benefits:

  1. reduces "covered" metadata; and
  2. allows data race analysis to skip such functions.

Diff Detail

Event Timeline

melver created this revision.Feb 2 2023, 2:33 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 2 2023, 2:33 AM
melver requested review of this revision.Feb 2 2023, 2:33 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 2 2023, 2:33 AM
dvyukov added inline comments.Feb 2 2023, 2:42 AM
llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
383

What if we pretend these are atomic as well?

melver added inline comments.Feb 2 2023, 3:20 AM
llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
383

Marking things as atomic increases binary size. It's better to just not emit any metadata (less space used).

There are plenty function-local objects and if we mark all accesses to them as atomic, we'll end up with larger binaries.

Of course this will only help if all accesses in a function are non-escaping. If there's at least e.g. 1 global access, the function will end up being "covered" with atomics metadata again.

dvyukov added inline comments.Feb 2 2023, 3:23 AM
llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
383

But I think it's highly-likely a function also contains non-local accesses (esp for optimized builds with inlining where functions tend to be larger).
Maybe we should skip functions that contain only atomics accesses and local/non-interesting accesses (contains at least 1 interesting access).

melver updated this revision to Diff 494301.Feb 2 2023, 7:15 AM
melver edited the summary of this revision. (Show Details)

Make it more efficient by ignoring both non-shared and non-mutable addresses.

Herald added a project: Restricted Project. · View Herald TranscriptFeb 2 2023, 7:15 AM
Herald added a subscriber: Restricted Project. · View Herald Transcript
melver marked an inline comment as done.Feb 2 2023, 7:17 AM

PTAL.

Reworked some things to make it more efficient in the presence of constant data accesses.

llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
383

Changed it to look for shared+mutable.

So functions that access only non-escaping addresses and constant globals will be excluded entirely.

If a function is already covered by atomics metadata, constant globals will be considered atomic.

However, I think we still shouldn't pretend accesses to non-escaping memory are atomic because we'll increase binary size. Constant accesses should be relatively rare and can easily be optimized.

dvyukov added inline comments.Feb 2 2023, 9:29 PM
llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
383

Why this difference between global consts and non-escaping memory? Doesn't treating global consts as atomics also increase metadata size?
We marked coverage accesses as atomic to avoid "false" positives. But we don't need to do this for global consts.
If for non-escaping accesses it's profitable not mark them as atomics, shouldn't we do the same for global consts as well?

melver updated this revision to Diff 494561.Feb 3 2023, 2:21 AM
melver marked 2 inline comments as done.
melver edited the summary of this revision. (Show Details)

Don't pretend constant accesses are atomic if the function is "covered", so save on space.

llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
383

Right, I think right now our biggest risk is binary size, so I'll change it to not add unnecessary atomics metadata.

dvyukov accepted this revision.Feb 3 2023, 6:26 AM
This revision is now accepted and ready to land.Feb 3 2023, 6:26 AM