[llvm-commits] [llvm] r137232 - in /llvm/trunk/utils/TableGen: Record.cpp Record.h TGParser.cpp

David A. Greene greened at obbligato.org
Wed Aug 10 12:48:43 PDT 2011


Chris Lattner <clattner at apple.com> writes:

>> Use an Init (ultimately a StringInit) to represent the Record name.
>> This allows the name to be composed by standard TableGen operators.
>> This will enable us to get rid of the ugly #NAME# hack processing and
>> naturally replace it with operators.  It also increases flexibility
>> and power of the TableGen language by allowing record identifiers to
>> be computed dynamically.
>
> Hi David,
>
> This seems very strange.  Where are you going with this?

There are two things this can help address.

The first is changing the way #NAME# currently works.  That was
something I added back a year or so ago to support AVX.  It's clunky and
requires special processing in TGParser.  This change and some related
ones I have coming can be used to replace #NAME# with strconcat
operators.  Then the processing falls out natually from how operators
work.

The second is additional flexibility that result from allowing Record
names to be computed via operators.  It then becomes easy to add
instruction mnemonic prefixes, suffixes, etc. programmatically, which
allows the x86 SIMD .td file to be compressed dramatically.  This is
along the lines of the cleanup work we talked about last week.  It's
aimed to address what's currently in trunk, not based on any future
ISAs, though it will help tremendously when those come along as well.

Currently I don't have plans to replace #NAME# in any existing .td
files.  What I'd like to do is add the basic TableGen support to allow
me to introduce some of the factoring/abstraction mechanism I've used in
our tree to simplify (in my view) how x86 SIMD instructions are
specified.  But the examples won't make any sense without the
corresponding TableGen support so I'm working to incorporate that first.

With those code examples I think we can have a more productive
conversation about what we have at Cray and have better understanding
overall.  In other words, it's easier to talk about code than some
abstract idea.  :)

Make sense?

                              -Dave



More information about the llvm-commits mailing list