[cfe-commits] [PATCH] MS style inline assembly support

[Chandler Carruth]

I see this already landed in r158325, but I have comment:

Why are there no tests??

It seems unreasonable to add this much code without tests. It also feels
like this could be broken up more.

Why is libclang and RAV support tied to the initial patch? Couldn't we
start parsing these first, with test cases, layer on AST representations
and Sema with more tests, and finally visit them? We could also defer the
serialization stuff... anyways, in the future, I think it might be nice to
commit these new features incrementally, with tests for each stage.

It seems somewhat worrisome to commit to libclang support and enshrine its
API now, when the AST design sounds very much in flux.

-Chandler

On Mon, Jun 11, 2012 at 12:28 PM, Chad Rosier <mcrosier at apple.com> wrote:

>
> On Jun 9, 2012, at 12:47 PM, Chris Lattner wrote:
>
> >
> > On Jun 8, 2012, at 11:52 AM, Chad Rosier wrote:
> >
> >> The attached patch etches out a new code path for MS style inline
> assembly in the Parser, Sema, AST, and CodeGen.  This is _largely_ a WIP!
> >>
> >> The idea is to translate the MS style inline assembly into IR that is
> equivalent to the GNU style inline assembly.  That way the backend doesn't
> need to be modified (nor does our assembler implementation).  I was hoping
> to make further progress on this today, so please take a look if you have a
> quick second.
> >
> > Cool, I'm glad to see this get started.  While this style of asm is
> annoying to implement, I really like it that users of the compiler don't
> have to worry about operand constraints (which they're extremely likely to
> get wrong and then blame the compiler when something changes).
> >
> > Can you talk a bit about the envisioned design here?  How does the
> lexing of the asm work? How does name lookup of variables plug into the
> lexing?  Will this be completely x86 specific, or could we (in principle)
> extend it to support all targets that are interested?
>
> Bob, Eric and I are still hashing things out (i.e., semi-flying by the
> seat of our pants), but I can give you an idea of what we're thinking.
>  Interpret this both as a warning and a solicitation for input. :D
>
> Ideally, we would like for the front-end to interface with MC.  llvm-gcc
> used a table-driven approach that was independent from the backend; this is
> understandable because MC didn't exist at that time.  However, we'd like to
> avoid this because it reduces code duplication and moves us toward
> something that can be supported for all targets.  The specific design of
> the interface is still an open question and that somewhat dictates how the
> name lookup is handled.  Most of the lookup should be done in Sema (IMO).
>
> Eli has expressed concerns with how to represent the AST data structures,
> so I'm hoping to tackle this next.  For the most part, I suspect much of
> this will lots of incremental commits as we continue to hash out a plan.
>
> Sorry for being so vague, but this is definitely a WIP.
>
> > I really like that the backend won't have to change for this.  Do you
> envision the assembler switching to ".intel_syntax" before emitting one of
> these, or do you envision the trick that gcc/llvm-gcc's uses, where it
> completely rewrites all syntax into AT&T style (including operands)?
>
> Or at the very least we can minimize the changes. :)
>
> I'm inclined to push for the former, but this is certainly debatable.
>  Devang added support for MS/Intel syntax, but my understanding is that
> it's fairly untested.  This is likely the path of least resistance as the
> rewriting is non-trivial.
>
>  Chad
>
> >
> > -Chris
> >
> >
> >
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120611/ed159715/attachment.html>