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

[Jim Grosbach]

> On Jan 27, 2015, at 10:14 AM, Sergey Dmitrouk <sdmitrouk at accesssoftek.com> wrote:
> 
> 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.

There is no ordering guarantee.

> 
>>   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