[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