Re: Deprecating basic asm in a function - What now?

[James Greenhalgh <james dot greenhalgh at arm dot com>]

On Mon, Jun 20, 2016 at 08:01:24PM +0200, Michael Matz wrote:

> You see, the experiment shows that there's a gazillion uses of basic asms 
> out there.

I applied the proposed patch and built myself an allyesconfig AArch64 linux
kernel, the results were not pretty...

  make | grep "warning: Deprecated: asm" | wc -l
  8911

You could say I'm cheating as the asm in question appears in header files,
but this would be more than enough noise to guarantee the kernel will be
built with your warning disabled (and when the Linux kernel switches a
warning off, history suggests it won't be coming back on!). Remember that
while you might convince people to apply the proper fix for kernel version
N, you might struggle to get that fix backported across stable releases,
vendor releases, private releases etc. particularly when the alternative
fix of silencing the warning will appear to work fine.

There are 11 unique warnings for an arm64 Linux kernel build, 7 unique
warnings for an arm kernel build and 369 unique warnings for an x86_64
kernel build. Just for fun I counted how many warnings I get with x86_64
allyesconfig without filtering for unique; 14,697.

I haven't audited them to see which would be safe with the minimal changes
given in https://gcc.gnu.org/wiki/ConvertBasicAsmToExtended (that document
looks buggy, should it not reccommend that you always add a volatile when
moving from basic to extended?). The sorts of things I see in the arm/arm64
port are sleep loops for CPUs guarded by a conditional, asm guarded by other
asm barriers, text added to mergeable read-only section for common strings,
other things that are not obviously broken uses of basic asm.

On the other hand, some of the the x86_64 examples in lib/raid6/sse2.c are
super scary and have back-to-back instructions with hard-coded registers...

	asm volatile("pcmpgtb %xmm4,%xmm5");
	asm volatile("paddb %xmm4,%xmm4");
	asm volatile("pand %xmm0,%xmm5");

I can't defend them, and they look very fragile! Fixing this code would
require more substantial work.

I'm only looking at one consumer of our compiler here, but I think anything
that would cause the kernel community this much pain is a risky move, and is
indicative of how frequently we'd see this warning fire in the wild.
Permanently removing basic asm in a future GCC version is certainly not a
workable solution. So what is the value of a noisy warning?

Jeff and others have already come out against this patch, I'd like to add
my vote against it too.

Thanks,
James