<div dir="ltr">docs lgtm. In the future try to keep drive by's to a minimum (just as for code patches) (I see you're using git: it's super easy to isolate drive-by's with git. just use `git add -p` and make a tiny commit with the change (you might need to press "s" to split hunks if the drive-by is very near other code); during your next coffee break/compile after pulling upstream, you can then aggregate them into a single commit with `git rebase -i` and commit them directly (tiny obvious fixes like that don't need review)).<div>
<br></div><div>-- Sean Silva</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Nov 16, 2013 at 10:41 PM, Ahmed Bougacha <span dir="ltr"><<a href="mailto:ahmed.bougacha@gmail.com" target="_blank">ahmed.bougacha@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Nov 12, 2013 at 9:59 AM, Quentin Colombet <<a href="mailto:qcolombet@apple.com">qcolombet@apple.com</a>> wrote:<br>

> Hi Ahmed,<br>
><br>
> The code looks fine to me, but the additional documentation is a bit too<br>
> short.<br>
><br>
> +TableGen will also generate an enumeration consisting of all named Operand<br>
> +types defined in the backend, in the llvm::XXX::OpTypes namespace.<br>
> +<br>
><br>
> Indeed, I am not sure that it is clear that "types defined in the backend"<br>
> are the derived types in the backend. In my opinion the proposed phrasing<br>
> would suffix if and only if there is an example to illustrate it.<br>
> Unfortunately, you cannot reuse the XNORrr example as it does not have such<br>
> types. You have to add one.<br>
<br>
</div>Yup, added a subsubsection (with drive-by consistency changes) to demonstrate.<br>
<div class="im"><br>
> Out of curiosity, for your mapping how the “regular” types are mapped?<br>
<br>
</div>I assume you're talking about the immediate Operand types defined in<br>
Target.td (i8imm, i32imm, ..): they are members of the namespace, just<br>
like target-defined types. Added a sentence to the doc paragraph.<br>
We can move them to a common namespace should the need arise (it did not).<br>
<br>
Attached updated patch, thanks Quentin & Sean!<br>
<span class="HOEnZb"><font color="#888888"><br>
- Ahmed<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> Cheers,<br>
> -Quentin<br>
><br>
> On Nov 11, 2013, at 1:42 PM, Ahmed Bougacha <<a href="mailto:ahmed.bougacha@gmail.com">ahmed.bougacha@gmail.com</a>><br>
> wrote:<br>
><br>
> Hi Quentin, all,<br>
><br>
> Here's the next patch I had waiting for review.<br>
> In some situations it's very useful to have access to an enum of all<br>
> operand types (that is, instances of Operand in the target's tablegen<br>
> files).<br>
> My use for this is associating MI/SD-pattern level operands with the<br>
> underlying list of MC operand, and keeping track of that association.<br>
> I also sent a nice-to-have feature implemented in another email<br>
> (complete machine operand printing) that was very helpful for<br>
> debugging and testing.<br>
><br>
> Thanks!<br>
> - Ahmed<br>
><br>
> ---<br>
> docs/WritingAnLLVMBackend.rst       |  3 +++<br>
> utils/TableGen/InstrInfoEmitter.cpp | 31 +++++++++++++++++++++++++++++++<br>
> 2 files changed, 34 insertions(+)<br>
> <0001-TableGen-Generate-an-enum-for-all-named-Operand-type.patch><br>
><br>
</div></div></blockquote></div><br></div>