search for: loadi32

...efine vector load and stores for 64 i32 elements. so in x86instrinfo.td i wrote; def VMOV_256B_RM : I<0x6F, MRMSrcMem, (outs VR2048:$dst), (ins i32mem:$src), "vmov_256B_rm\t{$src, $dst|$dst, $src}", [(set VR2048:$dst, (v64i32 (scalar_to_vector (loadi32 addr:$src))))], IIC_MOV_MEM>, EVEX; def VMOV_256B_MR : I<0x7F, MRMDestMem, (outs), (ins i32mem:$dst, VR2048:$src), "vmov_256B_mr\t{$src, $dst|$dst, $src}", [(store (i32 (bitconvert VR2048:$src)), addr:$dst)], IIC_MOV_MEM&g...

...D<bits<4> subop, string asmstring, list<dag> pattern> : InstLD<subop, (outs GPR:$rD), (ins MEMri:$src), !strconcat(asmstring, "\t$rD, $src"), pattern> { bits<5> rD; bits<21> src; let Inst{25-21} = rD; let Inst{20-0} = src; } class LOADi32<bits<4> subop, string asmstring, PatFrag opNode> : LOAD<subop, asmstring, [(set (i32 GPR:$rD), (opNode ADDRri:$src))]>; let Itinerary = l_lwz in def LWZ : LOADi32<0x1, "l.lwz", load>; My instruction itinerary data looks like the following InstrItinData<l_...

...0, "INSERT_SUBREG", 0, 0, NULL, NULL, OperandInfo107 }, // Inst #5 = INSERT_SUBREG THe sixth field is zero, which means it doesn't have the the MayLoad flag set. x86-64 does have a few variants of INSERT_SUBREG, and one of them does have a load: def : Pat<(i64 (anyext (loadi32 addr:$src))), (INSERT_SUBREG (i64 (IMPLICIT_DEF)), (MOV32rm addr:$src), x86_subreg_32bit)>; This isn't currently being reflected in the InstrInfo tables. Naively, it seems like we should add a separate INSERT_SUBREGrm instructi...

> In particular, the LoadLatency is used in defaultDefLatency: > > /// Return the default expected latency for a def based on it's opcode. > unsigned TargetInstrInfo::defaultDefLatency( > const MCSchedModel &SchedModel, const MachineInstr *DefMI) const { > if (DefMI->isTransient()) > return 0; > if (DefMI->mayLoad()) > return

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.

...e: def addr : ComplexPattern<iPTR, 5, "selectAddr", [], [SDNPWantParent]>; The derefencing mov instruction looks like this: def MOV32rm : I<0x8B, MRMSrcMem, (outs GR32:$dst), (ins i32mem:$src), "mov{l}\t{$src, $dst|$dst, $src}", [(set GR32:$dst, (loadi32 addr:$src))], IIC_MOV_MEM>, OpSize32; So it expects a source address of type 'addr' which is 8 bytes. This leads to the following code being emitted when I apply my solution to problem 1: mov (%rcx),%eax In other words, the upper bits are not ignored. I am currently not sure...

...Pattern<iPTR, 5, "selectAddr", [], > [SDNPWantParent]>; > The derefencing mov instruction looks like this: > def MOV32rm : I<0x8B, MRMSrcMem, (outs GR32:$dst), (ins i32mem:$src), > "mov{l}\t{$src, $dst|$dst, $src}", > [(set GR32:$dst, (loadi32 addr:$src))], IIC_MOV_MEM>, OpSize32; > So it expects a source address of type 'addr' which is 8 bytes. This > leads to the following code being emitted when I apply my solution to > problem 1: > mov (%rcx),%eax > In other words, the upper bits are not ignored. &...

...what to replace 'load' with in the patterns above. I notice that we have these defm's in our XSTGInstrInfo.td file: defm LOADI64 : LoadOp< 0b1001010, "load", OpInfo_I64, II_LOAD1 >; defm LOADF64 : LoadOp< 0b1001010, "load", OpInfo_F64, II_LOAD1 >; defm LOADI32 : LoadOp< 0b1001010, "load", OpInfo_I32, II_LOAD1 >; defm LOADF32 : LoadOp< 0b1001010, "load", OpInfo_F32, II_LOAD1 >; defm LOADI16 : LoadOp< 0b1001010, "load", OpInfo_I16, II_LOAD1 >; defm LOADI8 : LoadOp< 0b1001010, "load", OpInfo_I8,...

...]>; def rm : SI<opc, MRMSrcMem, (outs DstRC:$dst), (ins x86memop:$src), asm, [(set DstRC:$dst, (OpNode (ld_frag addr:$src)))]>; } let isAsmParserOnly = 0 in { defm SInt_VCVTSI2SD : sse12_vcvt_avx_s<0x2A, GR32, FR64, sint_to_fp, i32mem, loadi32, "cvtsi2sd\t{$src, $dst, $dst|$dst, $dst, $src}">, XD, VEX; ... } let isAsmParserOnly = 1 in { defm VCVTSI2SD : sse12_vcvt_avx<0x2A, GR32, FR64, i32mem, "cvtsi2sd">, XD, VEX_4V; ... } If this style of mo...

...ure I understand. INSERT_SUBREG shouldn't have mayLoad / mayStore flags set. If it's not coalesced away, it's eventually lowered into a move. > > > x86-64 does have a few variants of INSERT_SUBREG, and one of > them does have a load: > > def : Pat<(i64 (anyext (loadi32 addr:$src))), > (INSERT_SUBREG (i64 (IMPLICIT_DEF)), (MOV32rm addr:$src), > > x86_subreg_32bit)>; > > > This isn't currently being reflected in the InstrInfo tables. > Naively, it seems like we should add a...

...ue. For example: IR Instruction %0 = load i32* getelementptr inbounds ([6 x i32]* @a, i32 0, i32 5), align 4, !tbaa !0 Two MachineInstrs lowed by this IR are shown following and used as This IR's second value in the map %vreg0<def> = MOVi32 <ga:@a>; GPR:%vreg0 %vreg1<def> = LOADi32 %vreg0, 20, pred:14, preg:%noreg; mem:LD4[getelementptr inbounds ([6 x i32]* @a, i32 0, i32 5)] (tbaa !="int") GPR:%vreg1,%vreg0 The reason I am looking for the above map is that I try to port Swing Modulo Scheduling code updated by Tanya M.Latter in LLVM1.7 to LLVM3.3. And this map w...

I am new to the LLVM backends, I am wondering how instruction selection is done in LLVM backends, I looked at the .td files in Target/X86, they all seem to be small and do not deal with common X86 instructions, i.e. mov, push, pop, etc. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

...>>>>>>>>>>>> "vmov_256B_rm\t{$src, $dst|$dst, $src}", >>>>>>>>>>>>>> [(set VR2048:$dst, (v64i32 >>>>>>>>>>>>>> (scalar_to_vector (loadi32 addr:$src))))], >>>>>>>>>>>>>> IIC_MOV_MEM>, EVEX; >>>>>>>>>>>>>> >>>>>>>>>>>>>> def VMOV_256B_MR : I<0x7F, MRMDestMem, (outs), (ins >>>&g...

...lt;0x31, MRMSrcMem, (outs VR_2048:$dst), (ins >>>>>> i2048mem:$src), >>>>>> "BROADCAST_256B\t{$src, $dst|$dst, $src}", >>>>>> [(set VR_2048:$dst, (v64i32 (X86VBroadcast ( >>>>>> loadi32 addr:$src))))], >>>>>> IIC_MOV_MEM>, TA; >>>>>> >>>>>> def: Pat<(v64f32 (X86VBroadcast (loadf32 addr:$src))), >>>>>> (BROADCAST_256B addr:$src)>; >>>>>> And it worked perfectly. &g...

...8:$dst), (ins >>>>>>>> i2048mem:$src), >>>>>>>> "BROADCAST_256B\t{$src, $dst|$dst, $src}", >>>>>>>> [(set VR_2048:$dst, (v64i32 (X86VBroadcast ( >>>>>>>> loadi32 addr:$src))))], >>>>>>>> IIC_MOV_MEM>, TA; >>>>>>>> >>>>>>>> def: Pat<(v64f32 (X86VBroadcast (loadf32 addr:$src))), >>>>>>>> (BROADCAST_256B addr:$src)>; >>>>>...

...e written in x86instravx512. i need to define my vector instructions so i wrote; def VMOV_256B_RM : I<0x6F, MRMSrcMem, (outs VR2048:$dst), (ins i32mem:$src), "vmov_256B_rm\t{$src, $dst|$dst, $src}", [(set VR2048:$dst, (v64i32 (scalar_to_vector (loadi32 addr:$src))))], IIC_MOV_MEM>, EVEX; def VMOV_256B_MR : I<0x7F, MRMDestMem, (outs), (ins i32mem:$dst, VR2048:$src), "vmov_256B_mr\t{$src, $dst|$dst, $src}", [(store (i32 (bitconvert VR2048:$src)), addr:$dst)], IIC_MOV_MEM&g...

...;>>> def VMOV_256B_RM : I<0x6F, MRMSrcMem, (outs VR2048:$dst), (ins >>>> i32mem:$src), >>>> "vmov_256B_rm\t{$src, $dst|$dst, $src}", >>>> [(set VR2048:$dst, (v64i32 (scalar_to_vector >>>> (loadi32 addr:$src))))], >>>> IIC_MOV_MEM>, EVEX; >>>> >>>> def VMOV_256B_MR : I<0x7F, MRMDestMem, (outs), (ins i32mem:$dst, >>>> VR2048:$src), >>>> "vmov_256B_mr\t{$src, $dst|$dst, $src}", &g...

...2048mem:$src), >>>>>>>>>>>> "BROADCAST_256B\t{$src, $dst|$dst, $src}", >>>>>>>>>>>> [(set VR_2048:$dst, (v64i32 (X86VBroadcast ( >>>>>>>>>>>> loadi32 addr:$src))))], >>>>>>>>>>>> IIC_MOV_MEM>, TA; >>>>>>>>>>>> >>>>>>>>>>>> def: Pat<(v64f32 (X86VBroadcast (loadf32 addr:$src))), >>>>>>>>>&...

On Wed, Jan 13, 2016 at 2:08 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 1/13/2016 2:26 PM, Phil Tomson via llvm-dev wrote: > >> I've got this PseudoOp defined: >> >> def SDT_RELADDR : SDTypeProfile<1, 2, [SDTCisInt<0>, SDTCisInt<1>]>; >> def XSTGRELADDR :