search for: addrri

...mentioned in the original post had solved my problems. I ended up >> having to explicitly add patterns for the f32 types to the >> InstrInfo.td. And then, it only seems to work if I add a pseudo >> instruction with the following selection pattern (store (f32 Regs: >> $src), ADDRri:$addr), rather than adding a pattern such as the >> following: >> >> def : Pat<(store (f32 Regs:$src), ADDRri:$addr), (ST32 Regs:$src, >> ADDRri:$addr)>; >> >> The above pattern produced the following error because the >> TargetOperandInfo for the 1 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 eve...

...ladimir Prus wrote: > >> >> 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, ADDR...

On Dec 3, 2007, at 12:53 PM, Vladimir Prus wrote: > > 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)]>; &...

...t the bitconvert patterns I mentioned in the original post had solved my problems. I ended up having to explicitly add patterns for the f32 types to the InstrInfo.td. And then, it only seems to work if I add a pseudo instruction with the following selection pattern (store (f32 Regs: $src), ADDRri:$addr), rather than adding a pattern such as the following: def : Pat<(store (f32 Regs:$src), ADDRri:$addr), (ST32 Regs:$src, ADDRri:$addr)>; The above pattern produced the following error because the TargetOperandInfo for the 1 operand of the store had a NULL register class. llvm/...

...patterns I > mentioned in the original post had solved my problems. I ended up > having to explicitly add patterns for the f32 types to the > InstrInfo.td. And then, it only seems to work if I add a pseudo > instruction with the following selection pattern (store (f32 Regs: > $src), ADDRri:$addr), rather than adding a pattern such as the > following: > > def : Pat<(store (f32 Regs:$src), ADDRri:$addr), (ST32 Regs:$src, > ADDRri:$addr)>; > > The above pattern produced the following error because the > TargetOperandInfo for the 1 operand of the store had a NU...

On 3/30/2016 4:42 PM, Rail Shafigulin via llvm-dev wrote: > i'm getting a > > Could not infer all types in pattern! > > error in my backend. it is happening on the following instruction: > > VGETITEM: (set GPR:{i32:f32}:$rD, (extractelt:{i32:f32} > VR:{v4i32:v4f32}:$rA, GPR:i32:$rB)). > > how do i make it use appropriate types? in other words if it is f32 then

i'm getting a Could not infer all types in pattern! error in my backend. it is happening on the following instruction: VGETITEM: (set GPR:{i32:f32}:$rD, (extractelt:{i32:f32} VR:{v4i32:v4f32}:$rA, GPR:i32:$rB)). how do i make it use appropriate types? in other words if it is f32 then use v4v32 and if it is i32 then use v4f32. i'm not sure even where to start? any help is appreciated.

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

On Feb 12, 2007, at 1:41 AM, Christopher Lamb wrote: > > selector refused to select certain ops (specifically stores) for some > instructions when the operand type wasn't the first type for the > register class. After some digging around I seem to have solved the > problem by creating bitconvert patterns between the types in the > register class like the following: > >

Hi All, I'm working on a back end for an architecture that makes use of multi- typed register classes. def MR: RegisterClass<"namespace", [type1, type2, ... ], ... > When running some preliminary tests I found that the instruction selector refused to select certain ops (specifically stores) for some instructions when the operand type wasn't the first type for the

...own scalar stores and loads (with the standard i64 registers), for example (from https://github.com/llvm-mirror/llvm/blob/master/lib/Target/BPF/BPFInstrInfo.td): class STOREi64<bits<2> Opc, string OpcodeStr, PatFrag OpNode> : STORE<Opc, OpcodeStr, [(OpNode i64:$src, ADDRri:$addr)]>; However, spills and loads with vector registers, created automatically at the border of basic-blocks use the scalar stores and loads and NOT the vector ones that are also defined. For example, I obtain this ASM code when compiling with my LLVM: std -512(r10), R(0)...

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

in llvm-3.6.2.src 1. when I put this around one of my instruction definitions in my target "InstrInfo.td" file, let TwoOperandAliasConstraint = "$dst = $rs1" in { } I do not see any TIED_TO in the generated GenInstrInfo.inc file for the OperandInfo used by the instruction, the question is what am I doing wrong ? 2. I've noticed that TwoOperandAliasConstraint

...s own scalar stores and loads (with the standard i64 registers), for example (from https://github.com/llvm-mirror/llvm/blob/master/lib/Target/BPF/BPFInstrInfo.td): class STOREi64<bits<2> Opc, string OpcodeStr, PatFrag OpNode> : STORE<Opc, OpcodeStr, [(OpNode i64:$src, ADDRri:$addr)]>; However, spills and loads with vector registers, created automatically at the border of basic-blocks use the scalar stores and loads and NOT the vector ones that are also defined. For example, I obtain this ASM code when compiling with my LLVM: std -512(r10), R(0)...

...d use vector register REGVEC0, which have type v8i64. For example, the TableGen definition of the LOAD instruction taken from BPFInstrInfo.td is: class LOADi64<bits<2> SizeOp, string OpcodeStr, PatFrag OpNode> : LOAD<SizeOp, OpcodeStr, [(set i64:$dst, (OpNode ADDRri:$addr))]>; So I am surprised that the instruction selector finds as match for operand i64:$dst the vector register REGVEC0, which has type v8i64 as defined below, inspired from lib/Target/Mips/MipsRegisterInfo.td: def MSA128D: RegisterClass<"Connex", [v8i64], 512,...

...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 outs, dag ins, string asmstr, list<dag> pattern> : F3<outs, ins, asmstr, pattern> { bits<13> simm13; let op = opVal; let...

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 problem is that our ISA does not support the instruction. Instead it should be modified as followed addi %fp, -20, %r2 ----------------> adds %fp, %r0, %r2 (i.e. mov...

Hi there, I have a mem address pattern basically copied from Sparc: def ADDRri : ComplexPattern<iPTR, 2, "SelectADDRri", [frameindex],[]> It can match FrameIndex<0> but was unable to match FrameIndex<1>. What is the difference between the two? How to match FrameIndex<1>? Thanks, Xiaochu -------------- next part -------------- An HTML attach...

...has some instructions using both memories. I want to be able to access both memories in C-programs through the address space attribute. I have two ideas so far: Either: use two sets of addressing modes in InstrInfo.td: def ADDRrr_A : ComplexPattern<i16, 2, “SelectADDRrr_A", [], []>; def ADDRri : ComplexPattern<i16, 2, "SelectADDRri", [frameindex], []>; and def ADDRrr_B : ComplexPattern<i16, 2, "SelectADDRrr_B", [], []>; Or: do something in one of the lowering functions to catch load and stores, look at their address space attribute to pick the right assem...