<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 6, 2012, at 1:03 PM, João Matos wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">1. How is clang going to discover the input operands, output operands,<br>

constraints, and clobbered registers?<br></blockquote><div><br></div><div>The approach you described sounds good to me. Reusing all the work done in the LLVM MC layer seems the right approach.</div></div></blockquote><div><br></div>Glad you agree.  We really shouldn't be replicating information in the frontend; this very error prone.</div><div><br><blockquote type="cite"><div class="gmail_quote"><div><br></div><div> </div>

<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">In the above example, the two asm statments are not valid assembly.<br>

Thus, the AsmParser cannot parse these statements without some modifications.<br></blockquote><div><br></div><div>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.

</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><br><blockquote type="cite"><div class="gmail_quote"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

3. Which syntax, AT&T or Intel, should be passed to the backend?<br></blockquote><div><br></div><div>I'd prefer modifying the backend and passing the original syntax. Even if it involves some modifications, the advantages you listed are worth it.</div></div></blockquote><div><br></div><div>Again, glad you agree.  I don't think the modification will be that extensive.</div><br><blockquote type="cite"><div class="gmail_quote">

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

4. How do we distinguish the assembly dialect at the IR level?<br></blockquote><div><br></div><div>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 (<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">iasyntaxatt</span>), it would be cleaner to have a generic asmsyntax attribute that could take att/intel values.</div></div></blockquote><div><br></div><div>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..</div><br><blockquote type="cite"><div class="gmail_quote">

<div> </div><div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">

5. How should the inline asm be represented in the AST?<br>

<br>

This is largely an open question and I'm still in the process of familiarize<br>

myself with the frontend.  Doing this in a sane way is going to be critical for<br>

providing good diagnostic information.<br></blockquote><div><br></div><div>At the moment it seems to be represented with a MSAsmStmt, which just provides a string representation of the assembly code. </div></div></blockquote><div><br></div><div>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 :)</div><br><blockquote type="cite"><div class="gmail_quote"><div>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.</div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div class="gmail_quote">

<div> </div><div><br></div></div>-- <br>João Matos<br>

</blockquote></div><br></body></html>