search for: v2i32

Hi everyone, I tried to declare multiple data type [i64, i32, v2i32] for a 64 bit register class GPR. It works OK but I have one problem that is hard to find. When I tried to map a load instruction of a v2i32 type (LOAD v2i32:$dst) to load GPR, it always generate two LOAD i32 instead of one LOAD v2i32. Any folds understand how this works? Xiaochu -------------- n...

...rary storage > %tmp.0 = alloca i32 > %tmp.1 = alloca i32 > %tmp.i = insertelement <2 x i32*> undef, i32* %tmp.0, i32 0 > %tmp = insertelement <2 x i32*> %tmp.i, i32* %tmp.1, i32 1 > ; Read from in1 and in2 > %in1.v = call <2 x i32> @llvm.masked.gather.v2i32(<2 x i32*> %in1, i32 > 1, <2 x i1> <i1 true, i1 true>, <2 x i32> undef) #1 > %in2.v = call <2 x i32> @llvm.masked.gather.v2i32(<2 x i32*> %in2, i32 > 1, <2 x i1> <i1 true, i1 true>, <2 x i32> undef) #1 > ; Store in1 to the alloca...

I'm having some troubles implementing vector support to our custom backend It seems that llvm cannot emulate shuffle with extracts, inserts and builds? I've enabled vector registers with addRegisterClass(MVT::v2i32, TCE::V2I32RegsRegisterClass); addRegisterClass(MVT::v2f32, TCE::V2F32RegsRegisterClass); and created patterns for most vector instructions, including insert, extract and build. I've tried to say setOperationAction(ISD::VECTOR_SHUFFLE, MVT::v2i32, Expand); setOperationAction(ISD::VECTOR_SHU...

...>> %tmp.1 = alloca i32 > >> %tmp.i = insertelement <2 x i32*> undef, i32* %tmp.0, i32 0 > >> %tmp = insertelement <2 x i32*> %tmp.i, i32* %tmp.1, i32 1 > >> ; Read from in1 and in2 > >> %in1.v = call <2 x i32> @llvm.masked.gather.v2i32(<2 x i32*> %in1, i32 > >> 1, <2 x i1> <i1 true, i1 true>, <2 x i32> undef) #1 > >> %in2.v = call <2 x i32> @llvm.masked.gather.v2i32(<2 x i32*> %in2, i32 > >> 1, <2 x i1> <i1 true, i1 true>, <2 x i32> undef) #1 >...

...e selection details in the end. Let me check that first... On Sat, Jul 4, 2015 at 4:05 PM Xiaochu Liu <xiaochu1122 at gmail.com> wrote: > Hi Matt, > > I tried debug-only=isel and have some more informations. > The steps before 'Legalized selection'( excluding it) all use v2i32 load. > At the step of 'Legalized selection', it replaced one v2i32 load by two i32 > load + shl+ or + bitcast (I have a pattern for convert from v2i32 to > 2*i32). In previous steps (initial, lowered, type-legalized), they all use > v2i32 load. > Can you please think of any...

...gt;>> >> %tmp.i = insertelement <2 x i32*> undef, i32* %tmp.0, i32 0 >>> >> %tmp = insertelement <2 x i32*> %tmp.i, i32* %tmp.1, i32 1 >>> >> ; Read from in1 and in2 >>> >> %in1.v = call <2 x i32> @llvm.masked.gather.v2i32(<2 x i32*> %in1, >>> i32 >>> >> 1, <2 x i1> <i1 true, i1 true>, <2 x i32> undef) #1 >>> >> %in2.v = call <2 x i32> @llvm.masked.gather.v2i32(<2 x i32*> %in2, >>> i32 >>> >> 1, <2 x i1> <i1...

...>> %tmp.i = insertelement <2 x i32*> undef, i32* %tmp.0, i32 0 >>>> >> %tmp = insertelement <2 x i32*> %tmp.i, i32* %tmp.1, i32 1 >>>> >> ; Read from in1 and in2 >>>> >> %in1.v = call <2 x i32> @llvm.masked.gather.v2i32(<2 x i32*> %in1, >>>> i32 >>>> >> 1, <2 x i1> <i1 true, i1 true>, <2 x i32> undef) #1 >>>> >> %in2.v = call <2 x i32> @llvm.masked.gather.v2i32(<2 x i32*> %in2, >>>> i32 >>>> >> 1, &l...

...gt; > > > > > > > > > > > >> ; Read from in1 and in2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> %in1.v = call <2 x i32> @llvm.masked.gather.v2i32(<2 x > > > > > > > >> i32*> > > > > > > > >> %in1, > > > > > > > >> i32 > > > > > > > > > > > > > > > > > > > > > > > > > > >...

...t;2 x i32*> undef, i32* %tmp.0, i32 0 >>>>>>> >> %tmp = insertelement <2 x i32*> %tmp.i, i32* %tmp.1, i32 1 >>>>>>> >> ; Read from in1 and in2 >>>>>>> >> %in1.v = call <2 x i32> @llvm.masked.gather.v2i32(<2 x i32*> >>>>>>> %in1, i32 >>>>>>> >> 1, <2 x i1> <i1 true, i1 true>, <2 x i32> undef) #1 >>>>>>> >> %in2.v = call <2 x i32> @llvm.masked.gather.v2i32(<2 x i32*> >>>>>&g...

...t; undef, i32* %tmp.0, i32 0 >>>>>>>> >> %tmp = insertelement <2 x i32*> %tmp.i, i32* %tmp.1, i32 1 >>>>>>>> >> ; Read from in1 and in2 >>>>>>>> >> %in1.v = call <2 x i32> @llvm.masked.gather.v2i32(<2 x i32*> >>>>>>>> %in1, i32 >>>>>>>> >> 1, <2 x i1> <i1 true, i1 true>, <2 x i32> undef) #1 >>>>>>>> >> %in2.v = call <2 x i32> @llvm.masked.gather.v2i32(<2 x i32*> >>&g...

Thanks. I'm gonna try tomorrow and let you know. On Thu, Jul 2, 2015 at 6:51 PM Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 07/02/2015 06:41 PM, Xiaochu Liu wrote: > > Hi Matt, > > > > I did call addRegisterClass in TargetLowering for all the possible > > types in the register. And for typecasting instructions (i32 to i64), > > it works.

...res, but i128 is not a legal type. The way we handle > this is to make a same sized vector type (v4i32) legal and then add a > loop to the TargetLowering constructor to Expand everything except loads and > stores. > > I'm not sure if the TypeLegalizer will promote i64 stores to v2i32, but > if not I think you can add a target DAGCombine for it. > > > I'm not sure if this is better or worse than Pete's suggestion, but it > may be worth a try. This solution is definitely less of a hack than mine :) Mine has the advantage of working with weird sized types...

Hi As 32-bit mode doesn't have 64-bit GPR, the sequence converting v2i32 to v2f32 is quite inefficient in 32-bit mode. This patch adds the custom lowering in 32-bit mode. In addition, it teaches DAG combine to transform (build_vec (Xint2fp x) (Xint2fp y) ..) to (Xint2fp (build_vec x y)) to reduce the strength on FP conversion unit. Thanks for your review Yours - Micha...

Hi, I was wondering if there is a way to specify macros to help shorten rewriting patterns like these: def : Pat <(v4i8 (mul (v4i8 IntRegs:$a), (v4i8 IntRegs:$b))), (v4i8 (VTRUNEHB (v4i16 (VTRUNEWH (v2i32 (VMPYH (v2i16 (EXTRACT_SUBREG (v4i16 (VSXTBH (v4i8 IntRegs:$a))), subreg_hireg)), (v2i16 (EXTRACT_SUBREG (v4i16 (VSXTBH (v4i8 IntRegs:$b))), subreg_hireg)))), (v2i32 (VMPYH (v2i16 (EXTRACT_SUBREG (v4i16 (VSXTBH (v4i8 IntRegs:$a)...

I would like to specialise build_vector for the case when one of the operands is undefined. How do I describe this? This is looking for an analog of specialisations like: def : Pat <v2i32 (build_vector i32:$x, (i32 0)),...>; but for an undefined, rather than zero, value. I can work around my ignorance in performDAGCombine but would prefer to add to the existing pattern matching. Thanks, Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: <htt...

Hi there, I'm trying to map extract_vector_elt use the following pattern in tbl file. Def : Pat <(i64 (extractelt v2i32:$src, 0)), (i64 (SRLIMM GPR:$src, 32))>; But the tblgen shows : Type inference contradiction found , forcing v2i32 to have a vector element of type i64 But the manual says this instruction allows return type to be larger than element type. Anyone can show me any pointers ? Thanks, Xiaochu -...

.... http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { // Vector "promotion" is basically just bitcasting and doing the operation // in a different type. For example, x86 promotes ISD::AND on v2i32 to // v1i64. EVT VT = Op.getValueType(); assert(Op.getNode()->getNumValues() == 1 && "Can't promote a vector with multiple results!"); EVT NVT = TLI.getTypeToPromoteTo(Op.getOpcode(), VT); DebugLoc dl = Op.getDebugLoc(); SmallVector<SDValue, 4> Op...

Notice that PromoteVectorOp is called after the type legalization legalized all of the types in the program. It legalizes the *operations*, not the types. So, you should only see legal types (Legal types are types that fit into your registers). So, if your target has v2i32, I suspect that v4i8 is an illegal because it has a different size. -----Original Message----- From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Monday, July 30, 2012 21:26 To: Rotem, Nadav; Developers Mailing List Subject: RE: Vector promotion broken for <2 x [i8|i16]> Hrmm....

...gt; > Notice that PromoteVectorOp is called after the type legalization > legalized all of the types in the program. It legalizes the > *operations*, not the types. So, you should only see legal types > (Legal types are types that fit into your registers). So, if your > target has v2i32, I suspect that v4i8 is an illegal because it has a > different size. > > > -----Original Message----- > From: Villmow, Micah [mailto:Micah.Villmow at amd.com] > Sent: Monday, July 30, 2012 21:26 > To: Rotem, Nadav; Developers Mailing List > Subject: RE: Vector promotion b...

...elow is the IR corresponding to S->b, IIRC. %0 = load i64, *i64 ptr, align 4; %1 = %0 lshr 8; %2 = %1 and 255; Our target doesn't support load i64, so we have following code in XXXISelLowering.cpp setOperationAction(ISD::LOAD, MVT::i64, Custom); Transform load i64 to load v2i32 during type legalization. During op legalization, load v2i32 is found unaligned (4 v.s. 8), so stack load/store instructions are generated. This is one problem. Besides of that, our target has bitset/bitextract instructions, we want to use them on bitfield access, too. But don't know how to do...