[LLVMdev] Enhancing TableGen

David A. Greene greened at obbligato.org
Mon Oct 10 07:12:39 PDT 2011


Jakob Stoklund Olesen <stoklund at 2pi.dk> writes:

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

Can you give an example of the kind of search you want to do?

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

Why?  If we retain the ability to do the kind of searches you want,
wouldn't that be a good thing?

                              -Dave



More information about the llvm-dev mailing list