From: Linus Torvalds <torvalds@linux-foundation.org>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: peterz@infradead.org, Nadav Amit <namit@vmware.com>,
"the arch/x86 maintainers" <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@kernel.org>,
Brian Gerst <brgerst@gmail.com>,
Denys Vlasenko <dvlasenk@redhat.com>,
"H . Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu_ptr()
Date: Thu, 19 Oct 2023 15:39:12 -0700 [thread overview]
Message-ID: <CAHk-=wjvHDp+oiC4UZxivF6fCjKWFAAzgBYZdng6qe+ED6rLTg@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wj8qEwR1eGeJdup2q90WK7ZWBjpcXJEBi-TBp29p0n8oQ@mail.gmail.com>
Unrelated question to the gcc people (well, related in the way that
this discussion made me *test* this).
Lookie here:
int test(void)
{
unsigned int sum = 0;
for (int i = 0; i < 4; i++) {
unsigned int val;
#if ONE
asm("magic1 %0":"=r" (val): :"memory");
#else
asm volatile("magic2 %0":"=r" (val));
#endif
sum += val;
}
return sum;
}
and now build this with
gcc -O2 -S -DONE -funroll-all-loops t.c
and I get a *completely* nonsensical end result. What gcc generates is
literally insane.
What I *expected* to happen was that the two cases (with "-DONE" and
without) would generate the same code, since one has a "asm volatile",
and the other has a memory clobber.
IOW, neither really should be something that can be combined.
But no. The '-DONE" version is completely crazy with my gcc-13.2.1 setup.
First off, it does actually CSE all the asm's despite the memory
clobber. Which I find quite debatable, but whatever.
But not only does it CSE them, it then does *not* just multiply the
result by four. No. It generates this insanity:
magic1 %eax
movl %eax, %edx
addl %eax, %eax
addl %edx, %eax
addl %edx, %eax
ret
so it has apparently done the CSE _after_ the other optimizations.
Very strange.
Honestly, the CSE part looks like an obvious bug to me. The gcc
documentation states:
The "memory" clobber tells the compiler that the assembly code
performs memory reads or writes to items other than those listed in
the input and output operands (for example, accessing the memory
pointed to by one of the input parameters).
so CSE'ing any inline asm with a memory clobber sounds *very* dubious.
The asm literally told the compiler that it has side effects in
unrelated memory locations!
I don't think we actually care in the kernel (and yes, I think it
would always be safer to use "asm volatile" if there's some unrelated
memory locations that change), but since I was testing this and was
surprised, and since the obvious reading of the documented behavior of
a memory clobber really does scream "you can't combine those asms", I
thought I'd mention this.
Also, *without* the memory clobber, gcc obviously still does CSE the
asm, but also, gcc ends up doing just
magic1 %eax
sall $2, %eax
ret
so the memory clobber clearly does actually make a difference. Just
not a _sane_ one.
In testing, clang does *not* have this apparently buggy behavior (but
clang annoyingly actually checks the instruction mnemonics, so I had
to change "magic" into "strl" instead to make clang happy).
Hmm?
Linus
next prev parent reply other threads:[~2023-10-19 22:39 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 16:42 [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu_ptr() Uros Bizjak
2023-10-10 17:32 ` Linus Torvalds
2023-10-10 18:22 ` Uros Bizjak
2023-10-10 18:25 ` Nadav Amit
2023-10-10 18:42 ` Linus Torvalds
2023-10-10 18:37 ` Linus Torvalds
2023-10-10 18:41 ` Uros Bizjak
2023-10-10 18:52 ` Linus Torvalds
2023-10-11 7:27 ` Uros Bizjak
2023-10-11 7:45 ` Uros Bizjak
2023-10-11 19:40 ` Linus Torvalds
2023-10-11 18:42 ` Uros Bizjak
2023-10-11 19:51 ` Linus Torvalds
2023-10-11 19:52 ` Linus Torvalds
2023-10-11 20:00 ` Uros Bizjak
2023-10-11 22:37 ` Ingo Molnar
2023-10-11 23:15 ` H. Peter Anvin
2023-10-12 1:35 ` Josh Poimboeuf
2023-10-12 6:19 ` Ingo Molnar
2023-10-12 16:08 ` Josh Poimboeuf
2023-10-12 17:59 ` Ingo Molnar
2023-10-12 21:30 ` Josh Poimboeuf
2023-10-13 10:52 ` Ingo Molnar
2023-10-11 7:41 ` Nadav Amit
2023-10-11 19:37 ` Linus Torvalds
2023-10-11 21:32 ` Uros Bizjak
2023-10-11 21:54 ` Linus Torvalds
2023-10-12 15:19 ` Nadav Amit
2023-10-12 16:33 ` Uros Bizjak
2023-10-12 16:55 ` Uros Bizjak
2023-10-12 17:10 ` Linus Torvalds
2023-10-12 17:47 ` Linus Torvalds
2023-10-12 18:01 ` Uros Bizjak
2023-10-13 9:38 ` Uros Bizjak
2023-10-13 11:53 ` Uros Bizjak
2023-10-13 16:38 ` Linus Torvalds
2023-10-12 17:52 ` Uros Bizjak
2023-11-20 9:39 ` Use %a asm operand modifier to obtain %rip-relative addressing Uros Bizjak
2023-10-12 16:56 ` [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu_ptr() Linus Torvalds
2023-10-12 17:16 ` Linus Torvalds
2023-10-12 19:32 ` Nadav Amit
2023-10-12 19:40 ` Linus Torvalds
2023-10-16 18:52 ` Uros Bizjak
2023-10-16 19:24 ` Linus Torvalds
2023-10-16 20:35 ` Nadav Amit
2023-10-16 20:59 ` Linus Torvalds
2023-10-16 23:02 ` Linus Torvalds
2023-10-16 23:14 ` Linus Torvalds
2023-10-17 7:23 ` Nadav Amit
2023-10-17 19:00 ` Linus Torvalds
2023-10-17 19:11 ` Uros Bizjak
2023-10-17 21:05 ` Uros Bizjak
2023-10-17 21:53 ` Linus Torvalds
2023-10-17 22:06 ` Nadav Amit
2023-10-17 22:29 ` Nadav Amit
2023-10-18 7:46 ` Uros Bizjak
2023-10-18 9:04 ` Uros Bizjak
2023-10-18 10:54 ` Nadav Amit
2023-10-18 12:14 ` Uros Bizjak
2023-10-18 13:15 ` Uros Bizjak
2023-10-18 14:46 ` Nadav Amit
2023-10-18 15:17 ` Uros Bizjak
2023-10-18 16:03 ` Nadav Amit
2023-10-18 16:26 ` Linus Torvalds
2023-10-18 17:23 ` Uros Bizjak
2023-10-18 18:11 ` Linus Torvalds
2023-10-18 18:08 ` Uros Bizjak
2023-10-18 18:15 ` Linus Torvalds
2023-10-18 18:26 ` Uros Bizjak
2023-10-18 19:33 ` Uros Bizjak
2023-10-18 20:17 ` Nadav Amit
2023-10-18 20:22 ` Linus Torvalds
2023-10-18 20:34 ` Linus Torvalds
2023-10-18 20:51 ` Uros Bizjak
2023-10-18 21:09 ` Uros Bizjak
2023-10-18 21:10 ` Linus Torvalds
2023-10-18 21:40 ` Uros Bizjak
2023-10-18 22:40 ` Linus Torvalds
2023-10-18 23:06 ` Linus Torvalds
2023-10-19 7:04 ` Uros Bizjak
2023-10-19 16:59 ` Linus Torvalds
2023-10-19 17:21 ` Uros Bizjak
2023-10-19 18:06 ` Linus Torvalds
2023-10-19 18:16 ` Uros Bizjak
2023-10-19 18:49 ` Linus Torvalds
2023-10-19 19:07 ` Linus Torvalds
2023-10-20 7:57 ` Uros Bizjak
2023-10-19 21:04 ` Linus Torvalds
2023-10-19 22:39 ` Linus Torvalds [this message]
2023-10-20 8:08 ` Uros Bizjak
2023-10-19 8:44 ` Peter Zijlstra
2023-10-19 8:54 ` Peter Zijlstra
2023-10-19 17:04 ` Linus Torvalds
2023-10-19 18:13 ` Peter Zijlstra
2023-10-19 18:22 ` Linus Torvalds
2023-10-19 18:37 ` Uros Bizjak
2023-10-19 9:07 ` Peter Zijlstra
2023-10-19 9:23 ` Uros Bizjak
2023-10-18 20:42 ` Uros Bizjak
2023-10-19 16:32 ` Uros Bizjak
2023-10-19 17:08 ` Linus Torvalds
2023-10-18 18:29 ` Nadav Amit
2023-10-18 16:12 ` Linus Torvalds
2023-10-18 17:07 ` Uros Bizjak
2023-10-18 18:01 ` Linus Torvalds
2023-10-16 21:09 ` Uros Bizjak
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='CAHk-=wjvHDp+oiC4UZxivF6fCjKWFAAzgBYZdng6qe+ED6rLTg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=brgerst@gmail.com \
--cc=dvlasenk@redhat.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=namit@vmware.com \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=ubizjak@gmail.com \
--cc=x86@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;
as well as URLs for NNTP newsgroup(s).