search for: f3_2

I'm a bit confused as to how some of the values in a Sparc store instruction actually come to be set. The Sparc backend defines a store as: def STri : F3_2<3, 0b000100, (outs), (ins MEMri:$addr, IntRegs:$src), "st $src, [$addr]", [(store IntRegs:$src, ADDRri:$addr)]>; F3_2 and it's superclasses are defined as follows: class F3_2<bits<2> opVal, bits<6> op3val, dag o...

Suppose I have a target that does not have register+constant addressing mode. Then, I have DAG like: (store ..., (frameindex)) Targets like SPARC have the following patterns to catch this: def ADDRri : ComplexPattern<i32, 2, "SelectADDRri", [frameindex], []>; def STri : F3_2<3, 0b000100, (outs), (ins MEMri:$addr, IntRegs:$src), "st $src, [$addr]", [(store IntRegs:$src, ADDRri:$addr)]>; Where ADDRri will eventually turn into register+constant addressing in assembler. The IA64 target has explicit case i...

...The GlobalAddress for variable c is replaced by an 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:$ds...

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

...have register+constant > addressing mode. Then, I have DAG like: > > (store ..., (frameindex)) > > Targets like SPARC have the following patterns to catch this: > > def ADDRri : ComplexPattern<i32, 2, > "SelectADDRri", [frameindex], []>; > def STri : F3_2<3, 0b000100, > (outs), (ins MEMri:$addr, IntRegs:$src), > "st $src, [$addr]", > [(store IntRegs:$src, ADDRri:$addr)]>; > > Where ADDRri will eventually turn into register+constant > addressing in assembler. > >...

...for variable c is replaced by an 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> { > .... > } > > defm ADD : F3_12<"add", 0b000000, add>; > > Instruction ADD output register class is IntRegs. It does not match > AddrRegs. That's why you...

Hello > Finally, I don't know how to describe following instructions in > MCoreInstrInfo.td, because of its variable ins/outs. Or what other files > should I use to finish this description? Do you need the isel support for them? If yes, then you should custom isel them. iirc ARM and SystemZ backends have similar instructions, while only the first one supports full isel for them. In

...addressing mode. Then, I have DAG like: >> >> (store ..., (frameindex)) >> >> Targets like SPARC have the following patterns to catch this: >> >> def ADDRri : ComplexPattern<i32, 2, >> "SelectADDRri", [frameindex], []>; >> def STri : F3_2<3, 0b000100, >> (outs), (ins MEMri:$addr, IntRegs:$src), >> "st $src, [$addr]", >> [(store IntRegs:$src, ADDRri:$addr)]>; >> >> Where ADDRri will eventually turn into register+constant >> addressing...

Hi, all: Now I'm working on writing a backend for Moto MCore, but I don't know how to describe some instructions. First, I've already written MCoreRegisterInfo.td like these: class MCoreReg<bits<4> num, string name> : Register<name> { let Namespace = "MCore"; field bits<4> Num = num; } def R0 : MCoreReg< 0, "R0">,

Hi The construct in sparc def LEA_ADDri : F3_2<2, 0b000000, (outs IntRegs:$dst), (ins MEMri:$addr), "add ${addr:arith}, $dst", [(set IntRegs:$dst, ADDRri:$addr)]>; generate instruction like : add %fp, -20, %l1 in my port it generate like : addi %fp, -20, %r2 But the...

...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<2, Op3Val, (ops IntRegs:$dst, IntRegs:$b, i32imm:$c), !strconcat(OpcStr, " $b, $c, $dst"), [(set IntRegs:$dst, (OpNode IntRegs:$b, simm13:$c))]>; } which allows it to use instructions like: defm AND : F3_12<"and&quot...

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

...3Val, 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<2, Op3Val, > (ops IntRegs:$dst, IntRegs:$b, i32imm:$c), > !strconcat(OpcStr, " $b, $c, $dst"), > [(set IntRegs:$dst, (OpNode IntRegs:$b, simm13:$c))]>; > } > > which allows it to use instructions like: > &g...