[LLVMdev] Enhancing TableGen

David A. Greene greened at obbligato.org
Thu Oct 6 12:42:38 PDT 2011

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

> On Oct 6, 2011, at 7:59 AM, David A. Greene wrote:
>> For example, I want to be able to do this:
>> defm MOVH :
>>  vs1x_fps_binary_vv_node_rmonly<
>>    0x16, "movh", undef, 0,
>>           // rr
>>           [(undef)],
>>           // 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)]]>;
> This kind of thing is very hard to read and understand.

What's hard about it?  I'm not trying to be agitational here.  I'm truly
wondering what I can do to make this more understandable.

> ISAs don't change a lot

Well, they do on some common architecutres.  :)

> .td files are read lot more than they are written.  I actually think
> it is preferable to leave some redundancy in the .td files, it makes
> it much easier to find things.

I had two goals when I designed our AVX implementation.  Make it easily
extensible to longer vector lengths while keeping it as readable as
possible.  I am certainly happy to make things more readable and welcome
lots of feedback in that area.  But the ability to quickly and easily
extend the ISA for new vector lengths is critical to us.  That drives
the generic pattern specification above and the !foreach/!subst stuff
you see in MultiPat.td.  As I explained in another message, I think a
lot of MultiPat.td can be cleaned up with some semi-clever uses of the
for proposal.

I actually find the above easier to read and grasp that the multitude of
individual patterns for each different kind of ADD, SUB, etc. because I
don't have to go searching to find out how each one is defined.  They're
all defined exactly the same way.

But of course, I've been working with this for a long time.  I'm glad to
be getting some feedback on it now.  :)


More information about the llvm-dev mailing list