[LLVMdev] TableGen and Greenspun

David A. Greene greened at obbligato.org
Thu Oct 6 07:59:25 PDT 2011

Jakob Stoklund Olesen <jolesen at apple.com> writes:

> The TableGen language seems to be growing Lisp macros from two
> different directions.
> Che-Liang Chiou added a preprocessor with for loops, and David Greene
> added multidefs.
> It seems that some kind of macro facility is needed, perhaps we should
> discuss what it is supposed to look like?

Don't throw the Greenspunning term around unless you really mean it.

The problem I solved via multidefs was this: how does one write a set of
Pat<> patterns in a generic way?

For example, I want to be able to do this:

defm MOVH :
    0x16, "movh", undef, 0,
           // rr
           // rm
           [(set DSTREGCLASS:$dst, 
                 (DSTTYPE (movlhps SRCREGCLASS:$src1,
                                 (DSTTYPE (bitconvert
                                             (v2f64 (scalar_to_vector
                                                       (loadf64 addr:$src2))))))))],
           // rr Pat
           // rm Pat
           [[(DSTTYPE (movlhps SRCREGCLASS:$src1, (load addr:$src2))),
             (MNEMONIC SRCREGCLASS:$src1, addr:$src2)],
            [(INTDSTTYPE (movlhps SRCREGCLASS:$src1, (load addr:$src2))),
             (MNEMONIC SRCREGCLASS:$src1, addr:$src2)]]>;

I need to have the various types substituted and the mnemonic with
appropriate suffixes substituted.  I need to have this done for each
Pat<> pattern in the list ("rm Pat" above).  To do this TableGen needs
to know something about the top-level defm (the "defm name," if you
will) and something about the types and classes the defm gets
instantiated with.

Therefore, I need some way to process a list of patterns and do
substitutions in the context of a specific defm and all of the classes
it inherits from.

I'm open to another solution but multidef has served its purpose well
and I would need equivalent functionality.

TableGen is missing a lot of functionality but I think it should be
added incrementally rather than rewritten in some grand scheme.


More information about the llvm-dev mailing list