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

[Chad Rosier]

On Jun 11, 2012, at 1:56 PM, Chandler Carruth wrote:

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

I've been using the tests from the llvm-gcc test suite, but didn't convert them into something that worked with the testing infrastructure.  I will do so now and I apologize for not doing this in the first place.

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

They don't have to be.  My approach for this first patch, which I'm guessing you don't agree with, was to stub out most the components.  I did this more so as a means of learning the code base then following strict coding paractices as this is unfamiliar territory to me.  Kind of a "forest for the trees" approach.  However, moving forward I will be taking a more incremental approach.

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

We could certainly take a table-driven approach and remove the dependency upon libclang, but that would be largely throw away work.  I also understand that we don't want an API that is a moving target.

> 
> -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/fd5b132a/attachment.html>