[LLVMdev] [cfe-dev] [RFC] MS-style inline assembly

[Chad Rosier]

On Aug 6, 2012, at 1:03 PM, João Matos wrote:

> 1. How is clang going to discover the input operands, output operands,
> constraints, and clobbered registers?
> 
> The approach you described sounds good to me. Reusing all the work done in the LLVM MC layer seems the right approach.

Glad you agree.  We really shouldn't be replicating information in the frontend; this very error prone.

> 
>  
> In the above example, the two asm statments are not valid assembly.
> Thus, the AsmParser cannot parse these statements without some modifications.
> 
> I'm not familiar how it works, but maybe a generic hook can be added in AsmParser, so when unknown identifiers are parsed, Clang can provide the needed information.

My though here was that I wanted the fronted to be able to probe MC, but not necessarily the opposite.  I want to avoid adding this kind of logic to the MC layer, but then again your suggestion might be the right approach.

I was thinking it would be nice if the AsmParser understood pseudo registers (i.e., register that represent a register class and not necessarily a specific register).  One problem with this approach, however, is that your allowing the AsmParser to accept invalid assembly.  This could be fixed by adding a switch for when we're parsing this in the context of MS-style inline asm parsing vs. real assembly.

> 
> 
> 3. Which syntax, AT&T or Intel, should be passed to the backend?
> 
> I'd prefer modifying the backend and passing the original syntax. Even if it involves some modifications, the advantages you listed are worth it.

Again, glad you agree.  I don't think the modification will be that extensive.

> 
>  
> 4. How do we distinguish the assembly dialect at the IR level?
> 
> I also agree about adding a new attribute to the IR. I'm not familiar with how IR metadata works, but instead of having specific syntax attributes (iasyntaxatt), it would be cleaner to have a generic asmsyntax attribute that could take att/intel values.

I don't think metadata would be the right approach as it would be rather heavy handed considering were only storing a bit or two of information.  An attribute is the right way to go, so this is really a discussion about syntax.  I think I prefer your syntax, but I'm not sure how this would be implemented.  I'll investigate..

>  
> 
> 5. How should the inline asm be represented in the AST?
> 
> This is largely an open question and I'm still in the process of familiarize
> myself with the frontend.  Doing this in a sane way is going to be critical for
> providing good diagnostic information.
> 
> At the moment it seems to be represented with a MSAsmStmt, which just provides a string representation of the assembly code.

This question concerns how we match the SourceLocations to the asm string/tokens.  For the time being, I'm less concerned with good diagnostics and more concerned with getting the functionality working.  I just wanted to point out that we should be thinking about this.. (but I've already got a lot on my plate :)

> As we parse it, it would be good to have a proper AST for invidual assembly statements. Maybe we could represent them using a list of MCInst. Not sure how the MC layer works, but maybe we would have to fix the locations to match the original source code locations.

I'm not sure we would want to store the MCInst(s) in the AST.  After we're done with semantic checking and we've created the IR representation (with inputs, outputs, clobbers, constraints, etc.), I don't think there's a reason for the MCInst(s) to persist.

>  
> 
> -- 
> João Matos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120806/50ce9584/attachment.html>