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

[João Matos]

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



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


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.



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


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


-- 
João Matos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120806/86dea6de/attachment.html>