[flang-commits] [lldb] [libcxx] [clang] [libc] [libcxxabi] [flang] [llvm] [lld] [msan] Unpoison indirect outputs for userspace using memset for large operands (PR #79924)
Fangrui Song via flang-commits
flang-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 flang-commits
mailing list