[LLVMdev] Enhancing TableGen

[Jakob Stoklund Olesen]

On Oct 8, 2011, at 6:19 AM, Che-Liang Chiou wrote:

> I understand if you don't want an extra layer of abstraction (which
> adds extra looking-ups to someone reading td files), but I think we
> can have for-loop inside a multiclass without abstractions.
> 
> --------------------
> multiclass sse_binop<opcode> {
> for type = [f32, f64, v4f32, v2f64]
>     regclass = [FP32, FP64, VR128, VR128]
>     suffix = [ss, sd, ps, pd] {
> 
>   def !toupper(suffix)#rr : Instr<
>     [(set (type regclass:$dst), (type (opcode (type regclass:$src1),
>                                               (type regclass:$src2))))]>;
>   def !toupper(suffix)#rm : Instr<
>     [(set (type regclass:$dst), (type (opcode (type regclass:$src1),
>                                               (type addr:$src2))))]>;
> }
> }
> --------------------

You are right that it is better without referring to other definitions, but what you are suggesting is still much harder to read than just expanding the loop. Especially if you are searching for the properties of a specific def.

Look, I understand the urge to eliminate redundancy. Every good programmer has it.

But for target descriptions, it simply isn't the right thing to do.

The TableGen multiclass construct can be used to clean up gratuitous redundancy in one dimension, like the ADD and SUB having the exact same variants. If it isn't overused, it even helps readability.

We are missing a mechanism for eliminating gratuitous sequential redundancy, and a for loop for top-level defs would help with that.

Please use PPCRegisterInfo.td as the primary use case for a for loop.

/jakob