search for: sse_binop

...e copy-n-paste 'def' statements as in the PTXInstInfo.td. 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 regclas...

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

...act most binary operations are: (set (type regclass:reg), (type (op (type regclass:reg), (type regclass:reg)))) So why write hundreds of patterns to express this? Using the for-loop syntax: // WARNING: Pseudo-code, many details elided for presentation purposes. multiclass binop<opcode> : sse_binop<opcode>, avx_binop<opcode>; 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:$...

...et (type regclass:reg), (type (op (type regclass:reg), (type regclass:reg)))) > > So why write hundreds of patterns to express this? Using the for-loop > syntax: > > // WARNING: Pseudo-code, many details elided for presentation purposes. > > multiclass binop<opcode> : sse_binop<opcode>, avx_binop<opcode>; > > 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:$d...

...(set (type regclass:reg), (type (op (type regclass:reg), (type regclass:reg)))) > > So why write hundreds of patterns to express this?  Using the for-loop > syntax: > > // WARNING: Pseudo-code, many details elided for presentation purposes. > > multiclass binop<opcode> : sse_binop<opcode>, avx_binop<opcode>; > > 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...

My purpose is to eliminate copy-paste style of programming in td files as much as possible, but only to a point that the new language constructs do not create too much overhead/readability-downgrade. In other words, I am targeting those low-hanging fruit of copy-paste programmings in td files that are eliminated by a simple for-loop syntax. The repetitive patterns I observed in PTX backend (and

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

On Oct 7, 2011, at 2:23 PM, David A. Greene wrote: >> As repeated many times on this thread, the most common operation that >> a .td file must support is looking up an instruction and figuring out >> what its properties are and where they came from. > > Ok. What properties are most important to look up? I have found it > really easy to just run "tblgen

Jakob Stoklund Olesen <jolesen at apple.com> writes: > I think the for loops have merit, but not the way you want to use them. > > Some target descriptions have many sequential definitions, for example PowerPC/PPCRegisterInfo.td: > > // Vector registers > def V0 : VR< 0, "v0">, DwarfRegNum<[77, 77]>; > def V1 : VR< 1, "v1">,