[lldb] [libcxx] [clang] [libc] [libcxxabi] [flang] [llvm] [lld] [msan] Unpoison indirect outputs for userspace using memset for large operands (PR #79924)

Fangrui Song via cfe-commits cfe-commits at lists.llvm.org
Fri Feb 2 20:59:59 PST 2024


================
@@ -4552,16 +4552,22 @@ struct MemorySanitizerVisitor : public InstVisitor<MemorySanitizerVisitor> {
     }
     if (!ElemTy->isSized())
       return;
-    Value *SizeVal =
-      IRB.CreateTypeSize(MS.IntptrTy, DL.getTypeStoreSize(ElemTy));
+    auto Size = DL.getTypeStoreSize(ElemTy);
+    Value *SizeVal = IRB.CreateTypeSize(MS.IntptrTy, Size);
     if (MS.CompileKernel) {
       IRB.CreateCall(MS.MsanInstrumentAsmStoreFn, {Operand, SizeVal});
     } else {
       // ElemTy, derived from elementtype(), does not encode the alignment of
       // the pointer. Conservatively assume that the shadow memory is unaligned.
+      // When Size is large, avoid StoreInst as it would expand to many
+      // instructions.
       auto [ShadowPtr, _] =
           getShadowOriginPtrUserspace(Operand, IRB, IRB.getInt8Ty(), Align(1));
-      IRB.CreateAlignedStore(getCleanShadow(ElemTy), ShadowPtr, Align(1));
+      if (Size <= 32)
----------------
MaskRay wrote:

Thanks for your previous comment about the interceptor. The committed patch does contain this description:
"The intrinsic, if lowered to libcall, will use the msan interceptor."

Inline asm isn't commonly used:) This patch is for `=m` in extended asm, which I believe is typically used with small objects. I guess 32 and 64 won't make a difference.

https://github.com/llvm/llvm-project/pull/79924


More information about the cfe-commits mailing list