[PATCH] MC: provide the ability to disable assembly parsing

[Daniel Sanders]

My understanding of GCC is that it doesn't parse inline assembly except in so far as locating and expanding the %<digit> placeholders. The assembly itself is just a block of text.
Assuming that understanding is correct, 1 and 3 would be closer to GCC's approach.

My personal preference would be to only have 3 as far as possible. Either 1/2 are necessary to support targets that do not sufficiently support the integrated assembler but are a migration path. This view is based on the idea that even if 'clang -S' succeeds with no errors, 'clang -integrated-as' will later assemble the assembly file and will error at that point. Essentially by parsing inline assembly when -S is used, we are merely moving the error one command earlier. However, I've realised the problem with this view. I can easily believe that some build systems will configure themselves with clang as the compiler, and gas as a standalone assembler. The result would be that there are two assemblers involved in the build. .c->.o would be compiled with clang, and assembled with 'clang -integrated-as' while .c->.s->.o would be compiled with clang and assembled with gas. With that realization in mind, my preference would be for 2 and 3. Warnings should be emitted for 2 so that we get bug reports about assembly we can't handle.

As a side-note, updating autoconf/cmake so that they acknowledge that clang is also an assembler on some targets may be a sensible thing to do. This should prevent mixing 'clang -integrated-as' and gas and return us to the view where the integrated assembler will eventually assemble the file.

> -----Original Message-----
> From: Renato Golin [mailto:renato.golin at linaro.org]
> Sent: 20 February 2014 11:38
> To: dwmw2 at infradead.org; compnerd at compnerd.org
> Cc: llvm-commits at cs.uiuc.edu; cfe-commits at cs.uiuc.edu;
> amara.emerson at arm.com; Daniel Sanders
> Subject: Re: [PATCH] MC: provide the ability to disable assembly parsing
> 
> 
> 
> ================
> Comment at: include/llvm/MC/MCAsmInfo.h:310-315
> @@ -309,2 +309,8 @@
> 
> +    /// Should we parse inline assembly?
> +    /// The integrated assembler will usually parse inline assembly.  However,
> +    /// when simply generating an object file, it can be useful to prevent this
> +    /// (e.g. the Linux kernel uses it as a fancy preprocessor).
> +    bool ValidateInlineASMSyntax;
> +
>    public:
> ----------------
> Daniel Sanders wrote:
> > Isn't this the same as UseIntegratedAssembler above?
> Now, reading the comment above, I agree with you that the semantics is
> close enough so that we can merge them. I think Saleem's approach to flags
> was too conservative.
> 
> I can see the following states:
> 
> 1. We don't even parse, just dump text.
> 2. We parse, but don't fail on error (like GNU) 3. We parse and fail on errors
> 
> We need to dump one of them to have only one flag in which case it can be
> either:
> 
> * 1 and 3, as it is today, but we'll need to disable the parser by default even
> with IAS on for -S output, and that's what Saleem's patch is trying to do
> * 2 and 3, as I proposed on my first comment, and was the original
> assumption for enabling the IAS on -S output in the first place
> 
> I'd rather have any of them than what we have now, but I'm not completely
> convinced either is the best.
> 
> I still slightly prefer 2 and 3 on the grounds that it was our original agreement
> (me, you, Jim), and it will enable us to do more with inline assembly (ex.
> .code16/.code32) without breaking code that depends on weird behaviour
> (ex. macros). Also, other folks (Chandler) are preferring this solution.
> 
> 
> http://llvm-reviews.chandlerc.com/D2839