From: Hui Su <sh_def@163.com>
To: Marco Elver <elver@google.com>
Cc: dvyukov@google.com, kasan-dev@googlegroups.com, corbet@lwn.net,
skhan@linuxfoundation.org, rdunlap@infradead.org,
workflows@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/4] kcsan: add targeted watchpoint matching
Date: Fri, 16 Oct 2026 00:27:05 +0900 [thread overview]
Message-ID: <179207802520.771660.5931695730876285158@163.com> (raw)
In-Reply-To: <CANpmjNN0_EX8Tug6UFp=sap_Zv3QH1PnEn4GPGSKSHEU72W6zg@mail.gmail.com>
> 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.
prev parent reply other threads:[~2026-10-15 15:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 9:52 Hui Su
2026-10-15 14:33 ` Marco Elver
2026-10-15 15:27 ` Hui Su [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=179207802520.771660.5931695730876285158@163.com \
--to=sh_def@163.com \
--cc=corbet@lwn.net \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=skhan@linuxfoundation.org \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®