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

[Sergey Dmitrouk]

On Thu, Jan 22, 2015 at 04:38:06PM -0800, Reid Kleckner wrote:
>    To me the bug is not that macros aren't carried over into the next asm
>    blob, it's that they are carried over if you use -no-integrated-as and are
>    not carried if you don't. That inconsistency is the bug.

Initially I though that it's something related to the patch, while it
seems to be already existing inconsistency and the patch just moves it
from asm directive level to function level.

>    One way to fix the inconsistency would be to have LLVM's AsmPrinter
>    explicitly undef macros to prevent asm blobs from escaping macros.

Not sure if such behaviour is much better, it basically turns internal
LLVM inconsistency into "intensional" incompatibility with other compilers.
If macros are expanded beforehand and there is only one macros context per
module, everything should be fine with one more condition: functions in
the list module functions should be in top down order.

>    This is surprising to me. Typically we know the target up front, at least
>    well enough to pick between the ARM or X86 asm parsers, if not all the
>    subtarget features.

It failed during LTO tests in which one of object files doesn't specify
target triple, which is fine for LTO as it merges all modules before
processing them, but bad for expanding macros.

>    Nice! I guess one issue is that if you have code like this bad things
>    happen:
>    asm (".macro a ...")
>    void f() {
>       asm ("use macro a");
>    }
>    asm (".undef a ...")

You mean that it won't even compile because it's equivalent to the piece
below when processed by LLVM?

    asm (".macro a ..."
         "\n"
         ".undef a ...");
    void f() {
       asm ("use macro a");
    }

This behaviour is quite stable and a limitation of module level assembly
implementation in LLVM.  It doesn't seem like a big deal comparing to that
order of object files on command line for LTO linking defines order in
which module level assembly is combined, which can yield quite
unpredictable results.

>    Roundtripping through bitcode also kills use-list order unless you
>    explicitly ask to retain it. The constant folding issue just sounds like a
>    bug.

AsmReader just uses ConstExpr to create binary operations and ConstExpr
always folds everything it can during instruction construction.  Might
be considered to be a bug, although it's harmless in most cases.

-- 
Sergey