Skip to content

[msan][NFCI] Generalize handleIntrinsicByApplyingToShadow to allow alternative intrinsic for shadows #124831

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jan 28, 2025

Conversation

thurstond
Copy link
Contributor

@thurstond thurstond commented Jan 28, 2025

#124159 uses handleIntrinsicByApplyingToShadow for horizontal add/sub, but Vitaly recommends always using the add version to avoid false negatives for fully uninitialized data (#124662).

This patch lays the groundwork by generalizing handleIntrinsicByApplyingToShadow to allow using a different intrinsic (of the same type as the original intrinsic) for the shadow. Planned work will apply it to horizontal sub.

…ive intrinsic for shadows

llvm#124159 uses
handleIntrinsicByApplyingToShadow for horizontal add/sub, but Vitaly
recommends always using the add version to avoid false negatives for
fully uninitialized data (llvm#124662).

This patch lays the groundwork by generalizing handleIntrinsicByApplyingToShadow to allow using
a different intrinsic (of the same type as the original intrinsic) for the shadow. Planned work will apply it to horizontal sub.
@llvmbot
Copy link
Member

llvmbot commented Jan 28, 2025

@llvm/pr-subscribers-compiler-rt-sanitizer

@llvm/pr-subscribers-llvm-transforms

Author: Thurston Dang (thurstond)

Changes

#124159 uses handleIntrinsicByApplyingToShadow for horizontal add/sub, but Vitaly recommends always using the add version to avoid false negatives for fully uninitialized data (#124662).

This patch lays the groundwork by generalizing handleIntrinsicByApplyingToShadow to allow using a different intrinsic (of the same type as the original intrinsic) for the shadow. Planned work will apply it to horizontal sub.


Full diff: https://github.com/llvm/llvm-project/pull/124831.diff

1 Files Affected:

  • (modified) llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp (+13-6)
diff --git a/llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp b/llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
index 0d4be09846b604..d2d6a2391a686a 100644
--- a/llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
+++ b/llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
@@ -4049,7 +4049,8 @@ struct MemorySanitizerVisitor : public InstVisitor<MemorySanitizerVisitor> {
     //   consider this an acceptable tradeoff for performance.
     // To make shadow propagation precise, we want the equivalent of
     // "horizontal OR", but this is not available.
-    return handleIntrinsicByApplyingToShadow(I, /* trailingVerbatimArgs */ 0);
+    return handleIntrinsicByApplyingToShadow(
+        I, /*trailingVerbatimArgs*/ 0, /*shadowIntrinsicID=*/std::nullopt);
   }
 
   /// Handle Arm NEON vector store intrinsics (vst{2,3,4}, vst1x_{2,3,4},
@@ -4156,6 +4157,9 @@ struct MemorySanitizerVisitor : public InstVisitor<MemorySanitizerVisitor> {
   ///     shadow[out] =
   ///         intrinsic(shadow[var1], shadow[var2], opType) | shadow[opType]
   ///
+  /// Optionally, the intrinsic for the shadow can be replaced with another
+  /// intrinsic of the same type.
+  ///
   /// CAUTION: this assumes that the intrinsic will handle arbitrary
   ///          bit-patterns (for example, if the intrinsic accepts floats for
   ///          var1, we require that it doesn't care if inputs are NaNs).
@@ -4164,8 +4168,9 @@ struct MemorySanitizerVisitor : public InstVisitor<MemorySanitizerVisitor> {
   /// (tbl{1,2,3,4}).
   ///
   /// The origin is approximated using setOriginForNaryOp.
-  void handleIntrinsicByApplyingToShadow(IntrinsicInst &I,
-                                         unsigned int trailingVerbatimArgs) {
+  void handleIntrinsicByApplyingToShadow(
+      IntrinsicInst &I, unsigned int trailingVerbatimArgs,
+      std::optional<Intrinsic::ID> shadowIntrinsicID) {
     IRBuilder<> IRB(&I);
 
     assert(trailingVerbatimArgs < I.arg_size());
@@ -4187,8 +4192,9 @@ struct MemorySanitizerVisitor : public InstVisitor<MemorySanitizerVisitor> {
       ShadowArgs.push_back(Arg);
     }
 
-    CallInst *CI =
-        IRB.CreateIntrinsic(I.getType(), I.getIntrinsicID(), ShadowArgs);
+    CallInst *CI = IRB.CreateIntrinsic(
+        I.getType(), shadowIntrinsicID.value_or(I.getIntrinsicID()),
+        ShadowArgs);
     Value *CombinedShadow = CI;
 
     // Combine the computed shadow with the shadow of trailing args
@@ -4664,7 +4670,8 @@ struct MemorySanitizerVisitor : public InstVisitor<MemorySanitizerVisitor> {
     case Intrinsic::aarch64_neon_tbx3:
     case Intrinsic::aarch64_neon_tbx4: {
       // The last trailing argument (index register) should be handled verbatim
-      handleIntrinsicByApplyingToShadow(I, 1);
+      handleIntrinsicByApplyingToShadow(I, /*trailingVerbatimArgs*/ 1,
+                                        /*shadowIntrinsicID=*/std::nullopt);
       break;
     }
 

unsigned int trailingVerbatimArgs) {
void handleIntrinsicByApplyingToShadow(
IntrinsicInst &I, unsigned int trailingVerbatimArgs,
std::optional<Intrinsic::ID> shadowIntrinsicID) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the optional buys us much. We can jsut pass in the I.getInstrinsicID() from the caller?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, done!

@vitalybuka
Copy link
Collaborator

#124662 is not urgent to fix

Copy link
Collaborator

@vitalybuka vitalybuka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with @fmayer suggestion

@fmayer
Copy link
Contributor

fmayer commented Jan 28, 2025

This is "[NFC]" right?

@thurstond thurstond changed the title [msan] Generalize handleIntrinsicByApplyingToShadow to allow alternative intrinsic for shadows [msan][NFCI] Generalize handleIntrinsicByApplyingToShadow to allow alternative intrinsic for shadows Jan 28, 2025
@thurstond
Copy link
Contributor Author

This is "[NFC]" right?

Best I can do is NFCI

@thurstond
Copy link
Contributor Author

#124662 is not urgent to fix

Ack. It'll only take ~5 minutes though so I'll clean it up.

@thurstond thurstond merged commit 7bd9c78 into llvm:main Jan 28, 2025
5 of 7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants