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>