[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