> How does this change the generate asm (say on x86-64) of the fast
> path? (E.g. take a look at __tsan_read8 disasm.)
> We tried hard to e.g. avoid stack spills in the fast path, and if that
> affects fast path codegen negatively, that'd be not so nice.
Thanks, I checked this directly on x86-64, comparing baseline
4056b3c9d3c92ea45955641dbafeb9b960e146ef with patch 1
661e5012b2fd928a32b563c4337db3af9a71c743.
With GCC 15.2.0 and the exact RFC .config, __tsan_read8 has no new calls,
stack spills, stack-frame adjustment, or callee-saved register saves.
The relevant sequence from the linked image with the static key disabled is:
baseline (__tsan_read8):
+0xc5: cmp BYTE PTR [rax+0x10],0x0
+0xc9: jne ...
+0xcb: mov rdx,0xffffffffffffffff
+0xd2: xadd QWORD PTR gs:[...],rdx
patch 1, target disabled:
+0xc5: cmp BYTE PTR [rax+0x10],0x0
+0xc9: jne ...
+0xcb: 66 90 xchg ax,ax
+0xcd: mov rdx,0xffffffffffffffff
+0xd4: xadd QWORD PTR gs:[...],rdx
The original instruction stream is shifted by two bytes to make room for
the jump-label NOP. The target matcher is out of line on the cold branch.
In core.o, the symbol grows from 270 to 302 bytes, including that matcher.
For the Clang 21.1.8 comparison I used the same normalized .config for
both baseline and patch 1. This differs from the original RFC Clang build
by three Kconfig normalization changes. The paired __tsan_read8 comparison
likewise has no new calls, spills, stack-frame adjustment, or callee-saved
register saves. The disabled site is at +0x108 in core.o. The linked RFC
Clang image also has the 66 90 site. __tsan_read8 grows from 387 to 415
bytes in core.o due to the cold matcher.
I also checked __tsan_read1/2/4/16 and __tsan_write8; none gained calls
or spills. GCC's __tsan_write8 already has a push %rbx/pop sequence, which
is unchanged.
So I don't see a disabled-fast-path codegen regression from patch 1 in
either compiler build.
