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

Thurston Dang via llvm-commits llvm-commits at lists.llvm.org
Sat Dec 13 13:27:17 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)
----------------
thurstond wrote:

Is it possible to encode the change using only XorMask, without modifying ShadowBase?

When `ShadowBase == 0`, the compiler is able to optimize it out. A non-zero shadow base requires an extra instruction for every shadow calculation e.g, https://github.com/llvm/llvm-project/pull/171993/files#diff-91f63a475808bb3cc923763edeb8a60749a879ea775ce1ebcc31af6c867f91e7: 

```
  ; CHECK-NEXT:    [[TMP3:%.*]] = xor i64 [[TMP2]], 87960930222080

- ; CHECK-NEXT:    [[TMP4:%.*]] = inttoptr i64 [[TMP3]] to ptr
+ ; CHECK-NEXT:    [[TMP5:%.*]] = add i64 [[TMP3]], 2097152
+ ; CHECK-NEXT:    [[TMP4:%.*]] = inttoptr i64 [[TMP5]] to ptr
```

I suspect if the end addresses in kMemoryLayout were closed (e.g., 0x010000000000ULL - 1) instead of open, then it would be easy to do it entirely with XOR (though there might be other cleanup needed in MSan to handle closed end addresses).

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


More information about the llvm-commits mailing list