[LLVMdev] Enhancing TableGen

[David A. Greene]

Jim Grosbach <grosbach at apple.com> writes:

>>> We appreciate you thinking ahead about MIC, but we are against the
>>> massive refactoring and complicated abstraction scheme. We'll never
>>> accept those patches.
>> 
>> How about a less massive and complicated scheme?  I think we can
>> make some good improvements to the current spec that will help
>> with the MIC work.
>
> What do you have in mind? I don't think anyone is arguing that tblgen
> as-is is some paragon of virtue or anything. There's definitely room
> for improvements.

Two things immediately:

1. Make '#' (paste) a first-class citizen.  Make it an infix version of
  !strconcat().  This helps #2 by making use of the iterated values much
  simpler.  I also think it's good in its own right as it eliminates a
  special case from the TableGen parser.

2. Add the for loop capability integrated into the Parser.

Getting to #1:

The first step will be to modify the parser to get rid of the #NAME#
hack and turn paste into a first-class operator.  To transition things,
I propose that we temporarily add a built-in field in each Record
created by a defm called "NAME" with the value being the string parsed
as the defm ID.  Then parser lookup will find the right value for
everywhere #NAME# gets used.

Since NAME has a somewhat large potential for name conflict with some
user-created code, I would as a second step transition uses of #NAME# to
something like #@DEFM#.  The @ sign makes it unlikely to clash with a
user name and DEFM is more precise than NAME.  The built-in value NAME
will be named "@DEFM."  I am totally open to a different naming
convention.

Getting to #2:

This is pretty straightforward for for loops in multiclasses.  I will
steal the instantiation work I did for multidef as the mechanics are
exactly the same.  Some parser enhancements are all that's needed to
implement for loops in multiclasses.  I am pretty far along in this
already.

I'm going to design the parsing of for loops so that they can occur
almost anywhere and operate basically the same way everywhere.  I think
all that will be needed is to carry a bit more state around in the
ForLoop object created (field names seen in a class body, for example).
I think it's an incremental change for each kind of thing we'd like to
iteratively produce.

Those are the TableGen changes that I would find more immediately
useful.  If it works out like I'm envisioning, we can also get rid of
the more complicated operators (!foreach(), etc.).

Longer Term:

Beyond that, what I'd like to do is take the x86 SSE/AVX specification
as it is now and try to remove some of the cut-n-paste aspect without
abstracting things too much so that meaning is obscured.  I'm going to
rely on the community to check those changes and make suggestions if
they see problems.

My primary goal here is to stop the exponential growth of the x86 SIMD
.td files as Intel/AMD keep adding longer vector lengths.  Ideally, they
would not grow much at all as new vector types are added.  I've come
pretty close to that here and the for loop stuff will make it even
easier to accomplish and with more clarity.

So that's the 10,000' summary.

HTH

                             -Dave