Messages in this thread | | | From | Brian Gerst <> | Date | Mon, 11 May 2020 18:54:00 -0400 | Subject | Re: [PATCH] x86: support i386 with Clang |
| |
On Mon, May 11, 2020 at 3:34 PM Brian Gerst <brgerst@gmail.com> wrote: > > On Mon, May 11, 2020 at 2:46 PM Nick Desaulniers > <ndesaulniers@google.com> wrote: > > > > On Mon, May 11, 2020 at 11:09 AM Brian Gerst <brgerst@gmail.com> wrote: > > > This looks like the same issue that we just discussed for bitops.h. > > > Add the "b" operand size modifier to force it to use the 8-bit > > > register names (and probably also needs the "w" modifier in the 16-bit > > > case). > > > > While it does feel familiar, it is slightly different. > > https://godbolt.org/z/Rme4Zg > > That case was both compilers validating the inline asm, yet generating > > assembly that the assembler would choke on. This case is validation > > in the front end failing. > > > long long ret; > > switch (sizeof(ret)) { > > case 1: > > asm ("movb $5, %0" : "=q" (ret)); > > break; > > case 8:; > > } > > So if the issue here is that the output variable type is long long, > what code is using a 64-bit percpu variable on a 32-bit kernel? Can > you give a specific file that fails to build with Clang? If Clang is > choking on it it may be silently miscompiling on GCC.
On further investigation, 64-bit percpu operations fall back to the generic code on x86-32, so there is no problem with miscompiling here.
On a side note from looking at the preprocessed output of the percpu macros: they generate a ton of extra dead code because the core macros also have a switch on data size. I will take a stab at cleaning that up.
-- Brian Gerst
| |