[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