search for: opcstr

...gly sequential' definitions have no value, and I would welcome a for-loop construct that can create them. I think this was the primary motivation behind Che-Liang's proposal. I do NOT want to factor out redundancy from instruction definitions like this: multiclass PTX_FLOAT_3OP<string opcstr> { def rr32 : InstPTX<(outs RegF32:$d), (ins RndMode:$r, RegF32:$a, RegF32:$b), !strconcat(opcstr, "$r.f32\t$d, $a, $b"), []>; def ri32 : InstPTX<(outs RegF32:$d), (ins RndMode:$r, RegF32:$a, f32imm:$b),...

...e, and I > would welcome a for-loop construct that can create them. I think this > was the primary motivation behind Che-Liang's proposal. Ok. We agree here. > I do NOT want to factor out redundancy from instruction definitions like this: > > multiclass PTX_FLOAT_3OP<string opcstr> { > def rr32 : InstPTX<(outs RegF32:$d), > (ins RndMode:$r, RegF32:$a, RegF32:$b), > !strconcat(opcstr, "$r.f32\t$d, $a, $b"), []>; > def ri32 : InstPTX<(outs RegF32:$d), > (ins RndMode:$r, RegF...

...;CPU74", [i16], 16, (add R0, R1, R2, R3, R4, R5, R6, R7)>; def SSP : RegisterClass<"CPU74", [i16], 16, (add SP)>; The SP can not be used in general purpose arithmetic instructions, therefore I defined the following classes in MyTargetInstrInfo.td: class T5rr16alu<string opcStr, string altOpcStr, SDNode opNode, bits<4> opcode>: Type5 <opcode, (outs GR16:$rd), (ins GR16:$rn, GR16:$rs), AsmStr< opcStr, altOpcStr, "\t$rn, $rs, $rd">.n, [(set GR16:$rd, (opNode GR16:$rn, GR16:$rs)), (im...

Evan Cheng <evan.cheng at apple.com> writes: > David, we cannot accept the 'multidef' keyword. Please revert it. Working on it now. > We appreciate you thinking ahead about MIC, but we are against the > massive refactoring and complicated abstraction scheme. We'll never > accept those patches. How about a less massive and complicated scheme? I think we can make

...at's > really the canonical definition, right? In other words, .td files are write-only. This is not acceptable. It also doesn't answer '...and where they came from'. > This could be mitigated somewhat by doing something like this: > > class binary_pattern<string opcstr, string type> { > string pattern = !strconcat(opcstr, "$r."#type#"\t$d, $a, $b"); > } > > multiclass PTX_FLOAT_3OP<string opcstr> { > def rr32 : InstPTX<(outs RegF32:$d), > (ins RndMode:$r, RegF32:$a, RegF32:$b), >...

...for each unique type of instruction. The > current PTX_LOGIC version is for 3-operand instructions. A new multiclass > needs to be created for 2-operand logic instructions. I am trying to add a multiclass for 2-operand logic instructions. For example, multiclass PTX_LOGIC_2OP<string opcstr, SDNode opnode> { def ripreds : InstPTX<(outs Preds:$d), (ins Preds:$a), !strconcat(opcstr, ".pred\t$d, $a"), [(set Preds:$d, (opnode Preds:$a))]>; ... } But the error is still the same. Where else should I lo...

...st idential. In this case, although using a foo-loop adds a little bit cognitive cost to understand macro expansion, since it removes a lot of redundancy, I think it is actually more readable. (excerpt of PTXInstrInfo.td) ---------------------------------------- multiclass PTX_FLOAT_4OP<string opcstr, SDNode opnode1, SDNode opnode2> { def rrr32 : InstPTX<(outs RegF32:$d), (ins RegF32:$a, RegF32:$b, RegF32:$c), !strconcat(opcstr, ".f32\t$d, $a, $b, $c"), [(set RegF32:$d, (opnode2 (opnode1 RegF32:$a,...

...dd R0, R1, R2, R3, R4, R5, R6, R7)>; > def SSP : RegisterClass<"CPU74", [i16], 16, (add SP)>; > > The SP can not be used in general purpose arithmetic instructions, therefore I defined the following classes in MyTargetInstrInfo.td: > > class T5rr16alu<string opcStr, string altOpcStr, SDNode opNode, bits<4> opcode>: Type5 > <opcode, > (outs GR16:$rd), (ins GR16:$rn, GR16:$rs), > AsmStr< opcStr, altOpcStr, "\t$rn, $rs, $rd">.n, > [(set GR16:$rd, (opNode GR16:...

...or 3-operand instructions. A new multiclass needs to be created for 2-operand logic instructions. </pre> </blockquote> <pre wrap=""><!----> I am trying to add a multiclass for 2-operand logic instructions. For example, multiclass PTX_LOGIC_2OP<string opcstr, SDNode opnode> { def ripreds : InstPTX<(outs Preds:$d), (ins Preds:$a), !strconcat(opcstr, ".pred\t$d, $a"), [(set Preds:$d, (opnode Preds:$a))]>; ... } </pre> </blockquote> The error here is due t...

...ADD(HI(c), LO > (c)) during lowering. I assume the code-generator cant place values > in the address registers? All address-registers are elements in the > register sets IntRegs and AddrRegs. /// F3_12 multiclass - Define a normal F3_1/F3_2 pattern in one shot. multiclass F3_12<string OpcStr, bits<6> Op3Val, SDNode OpNode> { def rr : F3_1<2, Op3Val, (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c), !strconcat(OpcStr, " $b, $c, $dst"), [(set IntRegs:$dst, (OpNode IntRegs:$b, IntRegs: $c))]>; def ri...

....org/docs/TableGenFundamentals.html#multiclass Basically this lets you use one definition to implement multiple different instructions. For example, most instructions in the sparc target come in "reg,reg" and "reg,imm" forms. As such, it defines: multiclass F3_12<string OpcStr, bits<6> Op3Val, SDNode OpNode> { def rr : F3_1<2, Op3Val, (ops IntRegs:$dst, IntRegs:$b, IntRegs:$c), !strconcat(OpcStr, " $b, $c, $dst"), [(set IntRegs:$dst, (OpNode IntRegs:$b, IntRegs:$c))]>; def ri : F3_2&lt...

Hi! I'm writing a new back-end for a new architecture. First, I'll do some "tests" with an existing back-end (I chose the Sparc back-end). My architecture has special address-registers and I want to add such new address-registers to my Sparc back-end. 1) I defined a new register call AddrRegs 2) I registered the class AddrRegs (addRegisterClass(MVT::iPTR, .. )) 3) I

...t can't be "just" a preprocessing step. Also, I know I introduced the #..# "pasting" operation but I've found it to be too limiting. In this example: (Equivalent TableGen code with a for-loop) ---------------------------------------- multiclass PTX_FLOAT_4OP<string opcstr, SDNode opnode1, SDNode opnode2> { for nbit = [32, 32, 64, 64], op_suffix = [r, i, r, i], op_type = [RegF32, f32imm, RegF64, f64imm], op_node_type = [RegF32, fpimm, RegF64, fpimm] in { def rr#op_suffix#nbit : InstPTX<(outs RegF#nbit:$d),...

Jakob Stoklund Olesen <jolesen at apple.com> writes: > The TableGen language seems to be growing Lisp macros from two > different directions. > > Che-Liang Chiou added a preprocessor with for loops, and David Greene > added multidefs. > > It seems that some kind of macro facility is needed, perhaps we should > discuss what it is supposed to look like? Don't

The TableGen language seems to be growing Lisp macros from two different directions. Che-Liang Chiou added a preprocessor with for loops, and David Greene added multidefs. It seems that some kind of macro facility is needed, perhaps we should discuss what it is supposed to look like? /jakob

Hi, I'm trying to implement a new backend for an embedded CISC processor. Therefore I thought that it makes sense to take X86 target as a basis, to save some time. But when I look into the X86InstrInfo.td, I have a very strong feeling that it is one of the most complex instruction set descriptions compared to other targets. I can imagine that this is due to the complexity of X86's

...l definition, right? > > In other words, .td files are write-only.  This is not acceptable. > > It also doesn't answer '...and where they came from'. > >> This could be mitigated somewhat by doing something like this: >> >> class binary_pattern<string opcstr, string type> { >>  string pattern = !strconcat(opcstr, "$r."#type#"\t$d, $a, $b"); >> } >> >> multiclass PTX_FLOAT_3OP<string opcstr> { >>  def rr32 : InstPTX<(outs RegF32:$d), >>                     (ins RndMode:$r, RegF32:$a, Re...

On Sun, May 8, 2011 at 2:41 AM, 陳韋任 <chenwj at iis.sinica.edu.tw> wrote: > Hi, all > > I am trying to add "not" instruction support to PTX backend. > I add the line below in PTXInstrInfo.td, > > defm NOT : PTX_LOGIC<"not", not>; > > But I get errors below, > > >

Hi, Dan I add "not" instruction support in PTXInstrInfo.td as you suggested before. multiclass PTX_LOGIC_2OP<string opcstr,PatFrag opnode> { ... } Now I am trying to write test case for logic and shift operations. But I have a trouble in mapping LLVM IR to PTX IR for "not" instruction. The test case I wrote is, define ptx_device i16 @t4_u16(i16 %x) { ; CHECK: not.b16 rh0, rh1, rh2; ; CHECK-NEXT: ret;...

Hi, all I am trying to add "not" instruction support to PTX backend. I add the line below in PTXInstrInfo.td, defm NOT : PTX_LOGIC<"not", not>; But I get errors below, ------------------------------------------------------------------------------- Included from PTX.td:75: PTXInstrInfo.td:732:10: error: Value 'PTX_LOGIC::opnode' of type 'SDNode' is