[PATCH] [clang] add support for -W{no-,}inline-asm-syntax

[Joerg Sonnenberger]

On Thu, Feb 20, 2014 at 12:23:45PM +0000, David Woodhouse wrote:
> The semantic model I expect — admittedly for no better reason than it's
> what GCC has always done — is that the *text* within an inline asm
> statement is treated as opaque by the compiler.

But it isn't. This is a very strong case of behavior you got away with
due to deficits in the implementation. We had other examples of this,
like the fallout when LLVM started to correctly quote the section
attribute. People had been depending on the literal output of GCC to add
custom flags

I know there is sometimes a need to extract data structure sizes,
offsets and the like in a way that requires is both fast and
cross-compiling save. I suspect what the Linux kernel is doing is
similar to what NetBSD is doing with genassym. It's certainly somewhat
more work to create valid assembler for this purpose, but it can be
done.

> Inline asm has "constraints" which AIUI once upon a time matched the
> constraints that GCC had on actual machine instructions, which meant
> that the whole asm *string* ended up being scheduled as a machine
> instruction, and spat out to the .s file (or the pipe to the assembler)
> intact. The *compiler* never looked inside; only the assembler really
> saw it.
> 
> This semantic model is implicit in the very design of the constraints —
> in particular the fact that we have weird and wonderful
> platform-specific constraints like for example on AVR:
>      'w'
>           Registers from r24 to r31.  These registers can be used in
>           'adiw' command.

This argument strongly feels like a reversal of cause and effect. The
constraints are needed because the instructions you want to use require
them. The reuse of the internal constraints is just convenience, since
they already existed.

> The only reason for these explicit constraints to exist is because the
> semantic model is such that the compiler *doesn't* look inside the
> string that we give it, *see* that we're using an 'adiw' instruction,
> and decide to use appropriate registers for that.

No, they exist because the instructions can have side effects the
compiler can not reason about. That's a fundamentally different issue.
A very good example is the way the original SpeedStep works or how
virtualised drivers communicate with VMWare -- they write to a
special port to trigger SMI or a hypervisor trap and the arguments are
specified in some random register that the actual instruction doesn't
care about.

Joerg