From: Uros Bizjak <ubizjak@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: 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>,
Peter Zijlstra <peterz@infradead.org>,
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, 12 Oct 2023 19:52:16 +0200 [thread overview]
Message-ID: <CAFULd4Ytd9xShySxZcz9o6K9Nid9Sc=Dm=d=SkryCby06g2yQw@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wgUwPruc3MP6=vode2SawVpNgb8-szV1HYoc6E1wAaw=w@mail.gmail.com>
On Thu, Oct 12, 2023 at 7:10 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Thu, 12 Oct 2023 at 09:55, Uros Bizjak <ubizjak@gmail.com> wrote:
> >
> > An example:
>
> Oh, I'm convinced.
>
> The fix seems to be a simple one-liner, ie just
>
> - asm(__pcpu_op2_##size(op, __percpu_arg(P[var]), "%[val]") \
> + asm(__pcpu_op2_##size(op, __percpu_arg(a[var]), "%[val]") \
The effect of the change:
25542442 4387686 808452 30738580 1d50894 vmlinux-new.o
25546484 4387686 808452 30742622 1d5185e vmlinux-old.o
> and it turns out that we have other places where I think we could use that '%a',
>
> For example, we have things like this:
>
> asm ("lea sme_cmdline_arg(%%rip), %0"
> : "=r" (cmdline_arg)
> : "p" (sme_cmdline_arg));
>
> and I think the only reason we do that ridiculous asm is that the code
> in question really does want that (%rip) encoding. It sounds like this
> could just do
>
> asm ("lea %a1, %0"
> : "=r" (cmdline_arg)
> : "p" (sme_cmdline_arg));
>
> instead. Once again, I claim ignorance of the operand modifiers as the
> reason for these kinds of things.
>
> But coming back to the stable op thing, I do wonder if there is some
> way we could avoid the unnecessary reload.
>
> I don't hate Nadav's patch, so that part is fine, but I'd like to
> understand what it is that makes gcc think it needs to reload. We have
> other cases (like the ALTERNATIVE() uses) where we *have* to use
> inline asm, so it would be good to know...
>
> Is it just that "p" (in the constraint, not "P" in the modifier) ends
> up always being seen as a memory access, even when we only use the
> address?
>
> That part has never really been something we've been entirely clear
> on. We *are* passing in just the address, so the hope in *that* place
> is that it's only an address dependency, not a memory one.
Let's see the difference of:
--cut here--
int m;
void foo (void)
{
asm ("# %a0" :: "p" (&m));
}
void bar (void)
{
asm ("# %0" :: "m" (m));
}
--cut here--
The internal dump shows:
(insn:TI 5 2 15 2 (parallel [
(asm_operands/v ("# %a0") ("") 0 [
(symbol_ref:DI ("m") [flags 0x2] <var_decl
0x7f3175011bd0 m>)
]
[
(asm_input:DI ("p") rip.c:5)
]
[] rip.c:5)
(clobber (reg:CC 17 flags))
]) "rip.c":5:3 -1
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
vs:
(insn:TI 5 2 13 2 (parallel [
(asm_operands/v ("# %0") ("") 0 [
(mem/c:SI (symbol_ref:DI ("m") [flags 0x2]
<var_decl 0x7f3175011bd0 m>) [1 m+0 S4 A32])
]
[
(asm_input:SI ("m") rip.c:10)
]
[] rip.c:10)
(clobber (reg:CC 17 flags))
]) "rip.c":10:3 -1
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
The first argument is internally regarded as "constant":
-- Macro: CONSTANT_P (X)
'CONSTANT_P', which is defined by target-independent code, accepts
integer-values expressions whose values are not explicitly known,
such as 'symbol_ref', 'label_ref', and 'high' expressions and
'const' arithmetic expressions, in addition to 'const_int' and
'const_double' expressions.
So, it should not have any dependency.
Perhaps a testcase should be created and posted to gcc-bugs for
further analysis.
Uros.
next prev parent reply other threads:[~2023-10-12 17:52 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 [this message]
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
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='CAFULd4Ytd9xShySxZcz9o6K9Nid9Sc=Dm=d=SkryCby06g2yQw@mail.gmail.com' \
--to=ubizjak@gmail.com \
--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=torvalds@linux-foundation.org \
--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).