Re: [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu_ptr()

From: Uros Bizjak
Date: Thu Oct 19 2023 - 14:16:43 EST


On Thu, Oct 19, 2023 at 8:06 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, 19 Oct 2023 at 10:21, Uros Bizjak <ubizjak@xxxxxxxxx> wrote:
> >
> > > A compiler that were to rematerializes an inline asm (instead of
> > > spilling) would be a bad joke. That's not an optimization, that's just
> > > a crazy bad compiler with a code generation bug.
> >
> > But that is what the compiler does without volatile.
>
> Do you actually have a real case of that, or are basing it purely off
> insane documentation?
>
> Because remat of inline asm really _is_ insane.

The following testcase pushes the compiler to the limit:

--cut here--
extern void ex (int);

static int read (void)
{
int ret;

asm ("# -> %0" : "=r"(ret));
return ret;
}

int foo (void)
{
int ret = read ();

ex (ret);
asm volatile ("clobber" : : : "ax", "cx", "dx", "bx", "bp", "si", "di");

return ret;
}

extern int m;

int bar (void)
{
int ret = m;

ex (ret);
asm volatile ("clobber" : : : "ax", "cx", "dx", "bx", "bp", "si", "di");

return ret;
}
--cut here--

Please compile the above with -S -O2 -m32 (so we don't have to list
all 16 x86_64 registers).

And NO (whee...), there is no rematerialization of asm (foo() ). OTOH,
there is also no rematerialization from non-volatile memory (bar() ),
although it would be more optimal than spill to/fill from a frame pair
of moves. I wonder what are "certain circumstances" that the
documentation is referring to.

Uros.


Uros.