[PATCH] TableGen: Generate an enum for all named Operand types

[Ahmed Bougacha]

On Sat, Nov 16, 2013 at 11:01 PM, Sean Silva <silvas at purdue.edu> wrote:
> 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)).
>
> -- Sean Silva

Thanks for the advice! That's actually what I do, and diff master
whenever submitting a patch. I'll commit the drive-bys first from now
on. Went ahead and committed the non-squashed ones: r194978.

- Ahmed

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