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

[Sergey Dmitrouk]

Ping.

On Tue, Feb 10, 2015 at 09:52:27PM +0200, Sergey Dmitrouk wrote:
> Ping.
>
> So what else can be done about these changes?
>
> I'd like to fix the issue with expanding macros in general so that
> output does not depend on assembly being processed by compiler or
> external assembly, but for now it doesn't seem to be possible.
> Handling of inline assembly in LLVM might need greater changes to fix
> this issue as solution space is constrained by current design (I don't
> know, but looks like inline assembly wasn't there from the start,
> added later to provide support for most use cases).
>
> In any case, it's not what I was trying to do initially and probably
> deserves a PR if there is none yet.  If that's possible, I'd like to get
> these changes in for the sake of supporting wider range of inline
> assembly use cases (addressing any arising concerns like behaviour with
> enabled LTO).  My point is that the patch doesn't make things any worth,
> but rather allows more sources to be compiled with LLVM.
>
> Best regards,
> Sergey
>
> On Tue, Jan 27, 2015 at 10:44:52AM -0800, Jim Grosbach wrote:
> >
> > > 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