[LLVMdev] Enhancing TableGen

[Jakob Stoklund Olesen]

On Oct 6, 2011, at 12:42 PM, David A. Greene wrote:

> 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.

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.

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

>  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.

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

/jakob