[clang] [compiler-rt] [llvm] [RFC] [msan] make MSan up to 20x faster on AMD CPUs (PR #171993)

Kunqiu Chen via llvm-commits llvm-commits at lists.llvm.org
Sun Dec 14 00:58:52 PST 2025


================
@@ -443,8 +443,8 @@ static const MemoryMapParams Linux_I386_MemoryMapParams = {
 static const MemoryMapParams Linux_X86_64_MemoryMapParams = {
     0,              // AndMask (not used)
     0x500000000000, // XorMask
-    0,              // ShadowBase (not used)
-    0x100000000000, // OriginBase
+    0x200000,       // ShadowBase (== kShadowOffset)
----------------
Camsyn wrote:

I don’t think this is something that can be resolved simply by using a closed end (i.e. `mem2shadow(end - 1)`).

If we directly embed kShadowOffset into the XOR mask, as follows:
```cpp
#  define MEM_TO_SHADOW(mem)  (((uptr)(mem)) ^ (0x500000000000ULL + kShadowOffset))
```

Currently, kShadowOffset is 2 MiB, so this change would cause the lower 2 MiB and the upper 2 MiB within each 4 MiB shadow region to be swapped.

This may already be sufficient to mitigate the linear mapping issue  (the mapping is linear within each 2 MiB region, but it is still NOT linear.

This kind of non-linearity would require special handling for every contiguous copy, which is quite tricky. 
For example, with `memcpy(dst, src, n)`, we would no longer be able to directly apply the same operation to the shadow as `memcpy(mem2shadow(dst), mem2shadow(src), n)`, because the shadow corresponding to `src` may not be the start of the shadow range for the entire `[src, src + n)` region.

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


More information about the llvm-commits mailing list