[PATCH] [inline-asm] Fix scope of assembly macros

[Reid Kleckner]

In http://reviews.llvm.org/D6383#104321, @sdmitrouk wrote:

> > For LTO, what if we make Clang responsible for using the same asm context, and have it expand macros before creating the IR?
>
>
> Couldn't do this before creating the IR, need Target to parse inline asm.
>  Instead wrote a pass, which expands inline asm before module is emitted.
>  Please take a look and let me know what you think: http://reviews.llvm.org/P80


For MS inline asm, Clang already constructs an llvm::Target in clang/lib/Parse/ParseStmtAsm.cpp from the triple, so it is possible to do. I think this might be a good path forwards. Once we get to LLVM IR, we've basically lost source order, since inline functions can get emitted some time after their first use.

I don't know what happens when you have inline asm with operands like this:

  int global;
  asm volatile ( ".macro LEA_GLOBAL\nlea %0, %%rax\n.endm" : "m"(global));
  void *foo() {
    void *addr;
    asm volatile ( "LEA_GLOBAL\n\tmov %%rax, %0", : : "=m"(addr));
    return addr;
  }

Clang could opt to not expand macros containing operands in a subsequent asm blob.

<hr class="remarkup-hr" />

I'm not particularly in favor of the approach taken in this patch, where only module assembly can define macros which get used in functions. It's not very intuitive.

Honestly, this is all really horrible. I'm pretty content with the status quo. Maybe we can agree to not implement this? Users can this functionality with the C preprocessor.


http://reviews.llvm.org/D6383

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/