[LLVMdev] Enhancing TableGen

David A. Greene greened at obbligato.org
Fri Oct 7 07:34:32 PDT 2011


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

>>> 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.
>
> If you didn't write these patterns yourself, or if you wrote them six
> months ago, it is nearly impossible to figure out where a specific
> pattern came from, or where a specific instruction is defined.

I haven't had that problem.  Sure, I wrote the pattern but I'm really
not getting _what's_ hard about it.  It looks just like any other
pattern with the types replaced by parameters.

In this example, all of the MOVH[PS][SD] patterns are defined right
there, in one place.  IMHO this is much better than having the various
patterns scattered all over the .td file.

> It is hard enough mentally executing the current multiclasses.
> Injecting patterns into multi defms like this makes it much harder
> still.

So this:

>>>>          // 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)]]>;

is exactly the same patterns you see in some Pat<> defs today, except
those patterns are often completely separated from the "primary" pattern
defined by the defm (MOVH[PS][SD] in this case).

I find it easier to keep things in one place.

>>  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.
>
> This is where our priorities differ.
>
> Readability and maintainability are key.

Yes, they are very important.

> After all, we need to fix isel and codegen bugs more often than Intel
> and AMD add ISA extensions.

We need to do both.  Less code generally implies easier maintenance.
I've maintained way too much cut-n-paste code in my career and it's
always a waste of time.

I am very open to reworking things to be more readable and maintainable.
I think that the for loop extension along with Bruno's enhacements to
allow multiclass defs to inherit from multiclasses will go a long way to
making that happen.  These are both things that were on my TableGen
wishlist.

Give me a chance to try some things out and report back.  Fair?

                                -Dave



More information about the llvm-dev mailing list