search for: extract_vector_elt

...4 t55: v8i64 = BUILD_VECTOR Constant:i64<0>, Constant:i64<-1>, Constant:i64<-2>, Constant:i64<-3>, Constant:i64<-4>, Constant:i64<-5>, Constant:i64<-6>, Constant:i64<-7> t56: v8i64 = add t47, t55 t17: i64 = extract_vector_elt t16, Constant:i64<0> t26: ch = CopyToReg t0, Register:i64 %vreg16, t17 t18: i64 = extract_vector_elt t16, Constant:i64<1> t28: ch = CopyToReg t0, Register:i64 %vreg17, t18 t19: i64 = extract_vector_elt t16, Constant...

Hi All, I have a question about splitting 'EXTRACT_VECTOR_ELT' with 'v2i1'. I have a llvm IR code snippet as following: llvm IR code snippet: for.body: ; preds = %entry, %for.cond %i.022 = phi i32 [ 0, %entry ], [ %inc, %for.cond ] %0 = icmp ne <2 x i32> %vecinit1, <i32 0, i32 -23> %...

I'm trying to create a TableGen pattern to match extract_vector_elt. My pattern looks like this: (set i32:$dest, (extract_vector_elt v16i32:$src, i32:$index)) However, when I compile, I get an error: error: Variable not defined: 'extract_vector_elt' However, if I omit the rule and attempt to compile something that uses this functionality with cl...

...i1> %edgeMask_for.body1314, <4 x i1>* %27 * SelectionDAG before vector legalization ch = store<ST1[%16](align=4), trunc to v4i1> t0, t128, t32, undef:i64 * SelectionDAG after vector legalization ch = store<ST1[%16](align=4), trunc to i1> t0, t133, t32, undef:i64 t133: i32 = extract_vector_elt t128, Constant:i64<0> ch = store<ST1[%16](align=4), trunc to i1> t0, t136, t32, undef:i64 t136: i32 = extract_vector_elt t128, Constant:i64<1> ch = store<ST1[%16](align=4), trunc to i1> t0, t139, t32, undef:i64 t139: i32 = extract_vector_elt t128, Constant:i64<2> c...

...inal Message----- From: jingu at codeplay.com [mailto:jingu at codeplay.com] Sent: Friday, September 15, 2017 17:45 To: llvm-dev at lists.llvm.org; Demikhovsky, Elena <elena.demikhovsky at intel.com>; daniel_l_sanders at apple.com Subject: Re: Question about 'DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT' Can someone give the comment about it please? Thanks, JinGu Kang On 14/09/17 12:05, jingu at codeplay.com wrote: > Hi All, > > I have a question about splitting 'EXTRACT_VECTOR_ELT' with 'v2i1'. I > have a llvm IR code snippet as following: > > llvm IR c...

...t;4 x i1>* %27 > > * SelectionDAG before vector legalization > ch = store<ST1[%16](align=4), trunc to v4i1> t0, t128, t32, undef:i64 > > * SelectionDAG after vector legalization > ch = store<ST1[%16](align=4), trunc to i1> t0, t133, t32, undef:i64 > t133: i32 = extract_vector_elt t128, Constant:i64<0> > ch = store<ST1[%16](align=4), trunc to i1> t0, t136, t32, undef:i64 > t136: i32 = extract_vector_elt t128, Constant:i64<1> > ch = store<ST1[%16](align=4), trunc to i1> t0, t139, t32, undef:i64 > t139: i32 = extract_vector_elt t128, Con...

Hi, I have an issue with pattern matching. I have the following SelectionDAG: t13: i32 = extract_vector_elt t2, Constant:i64<1> That I am trying to match with the following pattern: def : Pat<(extractelt (v4i16 SingleReg:$v), 1), (SRADd1 SingleReg :$v, (i64 16))>; But for some reason the pattern does not match. It seems to be due to the fact extract_vector_elt's result type is i32...

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 la...

...16, 2017 00:38 To: Demikhovsky, Elena <elena.demikhovsky at intel.com>; daniel_l_sanders at apple.com <daniel_l_sanders at apple.com>; Jon Chesterfield <jonathanchesterfield at gmail.com> Cc: llvm-dev at lists.llvm.org Subject: Re: Question about 'DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT' Hi Elena, Thanks for your response. The store is ok but the extending load generates assertion after the store because MemVT is i8 and VT is i1 on following line. assert(MemVT.getScalarType().bitsLT(VT.getScalarType()) && "Should only be an extending load, not truncating!&quot...

...-Krzysztof Combining: t25: v2i16 = BUILD_VECTOR t27, t22 Before reduceBuildVecToShuffle SelectionDAG has 14 nodes: t0: ch = EntryToken t2: v4i16,ch = CopyFromReg t0, Register:v4i16 %0 // [a b c d] t26: v2i16 = extract_subvector t2, Constant:i32<0> // [a b] t27: i16 = extract_vector_elt t26, Constant:i32<0> // [a] t21: v2i16 = extract_subvector t2, Constant:i32<2> //[c d] t22: i16 = extract_vector_elt t21, Constant:i32<0> // [c] t25: v2i16 = BUILD_VECTOR t27, t22 // [a c] t18: ch,glue = CopyToReg t0, Register:v2i16 %m0, t25 t19: ch =...

> so I think we need to use non-extending load for element size less than 8bit on "DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT" like this roughly. > if (N->getOperand(0).getValueType().getVectorElementType().getSizeInBits() < 8) { > return DAG.getLoad(N->getValueType(0), dl, Store, StackPtr, MachinePointerInfo()); > } else { > return DAG.getExtLoad(ISD::EXTLOAD, dl, N->getValueType(0), Sto...

...gt;> * SelectionDAG before vector legalization >> ch = store<ST1[%16](align=4), trunc to v4i1> t0, t128, t32, undef:i64 >> >> * SelectionDAG after vector legalization >> ch = store<ST1[%16](align=4), trunc to i1> t0, t133, t32, undef:i64 >> t133: i32 = extract_vector_elt t128, Constant:i64<0> >> ch = store<ST1[%16](align=4), trunc to i1> t0, t136, t32, undef:i64 >> t136: i32 = extract_vector_elt t128, Constant:i64<1> >> ch = store<ST1[%16](align=4), trunc to i1> t0, t139, t32, undef:i64 >> t139: i32 = extract_vect...

...what other targets are doing. >>> >>> -- >>> Mehdi >>> >>> So I've added setOperationAction(ISD::BUILD_VECTOR, MVT::v4i32, Expand); to my code but that generated a following error: fatal error: error in backend: Cannot select: 0x6a84dc8: i32 = extract_vector_elt 0x6a85388, 0x6a813b0 [ORD=9] [ID=16] 0x6a85388: v4i32 = add 0x6a81098, 0x6a81e00 [ORD=8] [ID=15] 0x6a81098: v4i32 = add 0x6a81bf0, 0x6a84168 [ORD=6] [ID=12] 0x6a81bf0: v4i32,ch = CopyFromReg 0x6a2b7f0, 0x6a819e0 [ORD=5] [ID=8] 0x6a819e0: v4i32 = Register %vreg4 [ID=1] 0x6a...

On 18 August 2016 at 10:46, Matt Arsenault via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I think this is just intended as a quirk for some weird targets that have a > legal vector type, but the scalar type itself is not legal, so it requires > an implicit extension when extracting it. I think it's a pretty common RISC situation. I notice you deprecated the mismatching

Is there anywhere in the codebase that actually uses the ConvertAction to determine how conversion functions are lowered? In SDValue SelectionDAGLegalize::LegalizeOp(SDValue Op) ... case ISD::SINT_TO_FP: case ISD::UINT_TO_FP: case ISD::EXTRACT_VECTOR_ELT: Action = TLI.getOperationAction(Node->getOpcode(), Node->getOperand(0).getValueType()); This seems incorrect as SINT_TO_FP should be querying the convert action, and not the Operation action. i.e. it should be: case ISD::SINT_TO_FP: case ISD::UIN...

...isters. The way that I ended up handling this was to have different register classes for 1, 2, 3 and 4 component vectors. This made the generic cases very simple but still made swizzling fairly difficult. In order to get swizzling to work you only need to handle three SDNodes, insert_vector_elt, extract_vector_elt and build_vector while expanding the rest. For those three nodes I then custom lowered them to a target specific node with an extra integer constant per register that would encode the swizzle mask in 32bits. The correct swizzles can then be generated in the asm printer by decoding the integer const...

Hi, I'm trying to optimize the 'extract_vector_elt' for my SIMD microcontroller. The idea is, during DAG combination, to merge load/extract sequence into an architecture specific node. During Instruction Selection, this specific node will be target selected to an architecture specific instruction. By 'combination of DAG nodes' I underst...

Evan Cheng-2 wrote: > > Well, how many possible permutations are there? Is it possible to > model each case as a separate physical register? > > Evan > I don't think so. There are 4x4x4x4 = 256 permutations. For example: * xyzw: default * zxyw * yyyy: splat Even if can model each of these 256 cases as a separate physical register, how can I model the use of r0.xyzw in

...here anywhere in the codebase that actually uses the ConvertAction to determine how conversion functions are lowered? I don't see any. > > In SDValue SelectionDAGLegalize::LegalizeOp(SDValue Op) > > ... > case ISD::SINT_TO_FP: > case ISD::UINT_TO_FP: > case ISD::EXTRACT_VECTOR_ELT: > Action = TLI.getOperationAction(Node->getOpcode(), > Node->getOperand(0).getValueType()); > > This seems incorrect as SINT_TO_FP should be querying the convert action, and not the Operation action. > > i.e. it should be: >...

...targets are doing. >> >> -- >> Mehdi >> >> >> So I've added setOperationAction(ISD::BUILD_VECTOR, MVT::v4i32, Expand); to my code but that generated a following error: >> >> fatal error: error in backend: Cannot select: 0x6a84dc8: i32 = extract_vector_elt 0x6a85388, 0x6a813b0 [ORD=9] [ID=16] >> 0x6a85388: v4i32 = add 0x6a81098, 0x6a81e00 [ORD=8] [ID=15] >> 0x6a81098: v4i32 = add 0x6a81bf0, 0x6a84168 [ORD=6] [ID=12] >> 0x6a81bf0: v4i32,ch = CopyFromReg 0x6a2b7f0, 0x6a819e0 [ORD=5] [ID=8] >> 0x6a819e0: v4i32...