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

[David Woodhouse]

On Thu, 2014-02-20 at 03:25 -0800, Chandler Carruth wrote:
> On Thu, Feb 20, 2014 at 3:14 AM, David Woodhouse <dwmw2 at infradead.org>wrote:
> 
> > On Thu, 2014-02-20 at 02:02 -0800, Chandler Carruth wrote:
> > >
> > > This really doesn't make sense. So, we've not disabled the inline
> > > assembler, so we will eventually produce an error, but we don't ask it to
> > > validate the assembly about to be fed to itself (and errored on) while we
> > > have the full context of the source code to go with it? How is this
> > > reasonable behavior?
> > >
> > > Very fundamentally, LLVM's integrated assembler *is* going to assemble
> > the
> > > program.
> >
> > No. It isn't.
> >
> > Absolutely *nothing* is going to assemble this program.
> >
> > We invoke the compiler with the '-S' option. It's going to *compile* the
> > program, and spit out a .s file for us.
> >
> > Hence my comparison with a pre-processor. It makes as much sense for the
> > compiler in this case to be prodding and poking at the contents of
> > asm("") statements, as it does for a C preprocessor to barf because
> > "that's not valid C" when we use it for X keymap files.
> 
> 
> Do you expect it to validate the C code it compiles? Should it produce any
> warnings at all? Any errors? What is the limit?

The C code, yes.

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.

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.

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.

The whole *point* in inline assembly is that we're doing something that
we don't expect the compiler to understand. If the compiler could cope,
it'd probably be an intrinsic of some kind already. Thus, if there is
*any* prodding and poking at the contents of the inline asm, *even* in
the case where we *are* actually going to be assembling it with the
builtin assembler, it should be very clear that HERE BE DRAGONS. I'd
definitely go for the "warn, but never screw it up" option as discussed
elsewhere.

And in the case where the inline assembler is *not* being used, we
certainly shouldn't be surprised to see new instructions that the
compiler has never heard of. That's a common enough case. Or even
"garbage" such as the output we want in kernel/bounds.s:

#APP
->NR_PAGEFLAGS $23 __NR_PAGEFLAGS
#NO_APP

Basically, what I put inside the quotes in asm("") when I'm not using
your assembler is NOT YOUR BUSINESS.

> And I don't think that this precludes the interesting use cases here.
> Talking to Renato, it sounds much more like the validation is being
> entirely too pedantic and restrictive, not that we need to cease all
> validation.

I'm not sure what validation you're can meaningfully do on the above
example.

I suppose you can at least check that it is valid UTF-8? :)

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140220/695f78a4/attachment.bin>