[PATCH] Fix inline assembly that switches between ARM and Thumb modes

[Jim Grosbach]

He Renato,

It’s both a bit more complicated and a bit simpler than that. We don’t need hasRawTextSupport() specialization or explicit touching of the sub target feature bits. We’ll be added a target hook that will be called in AsmPrinterInlineAsm.cpp right after the inline asm blob is parsed and emitted (EmitInlineAsm()).  exitInlineAsm() or something like that. In that hook, we check if the current sub target mode matches the function attribute or not. If it doesn’t, emit a .thumb or .arm directive, whichever will get the assembler back to the right mode.

That is, we care whether the assembler and encoder are set up to handle the right instruction mode, not whether the executing code will be in the right mode when it gets there. The latter is not something we can realistically try to detect.

We very explicitly don’t want to add (yet?) parsing of the inline asm for the asm streamer. That’s an escape hatch for inline asm that uses constructs the integrated assembler can’t handle.

-Jim


On Dec 16, 2013, at 6:25 AM, Renato Golin <renato.golin at linaro.org> wrote:

> 
>  Hi Greg,
> 
>  As Jim said, this works for binary output:
> 
>    if (OutStreamer.hasRawTextSupport()) {
>      OutStreamer.EmitRawText(Str);
>      return;
>    }
> 
>  In the case of textual output, not only you're not checking for the error, but also you're not fixing anything. So, in that context, in half of the cases where this patch would be useful, it's not.
> 
>  Jim's proposal was to change the FeatureBits to its original state (and I add, emit a warning with the new inline asm warning system if changed), so that, at least, the common case is caught.
> 
>  I imagine there are cases (which would give anyone nightmares) for valid .arm/.thumb usage inside inline asm, but I think those cases are unstable, and a lot worse than the common case, so breaking them to fix this would make a bit of sense. I wouldn't cry over it, myself...
> 
>  The (better) alternative would be to parse the inline ASM on both output formats, but only add the instructions to the streamer on the binary one. Parsing inline ASM without output (in ASM mode) would serve two purposes:
> 
>  1. Validation of inline ASM, as an early warning system when the user included the wrong instruction set, or added invalid instructions, etc.
>  2. To identify changes that could impact further code generation, such as .code .text etc. and revert the changes before continue.
> 
>  This should make use of the new warning call back mechanism.
> 
> http://llvm-reviews.chandlerc.com/D2255