search for: extract_subvector

Hello, Working on my (currently out-of-tree) BG/Q PPC enhancements, I've run into the following problem with vector type legalization. Here's a quick example: Scalarize node result 0: 0x2348420: v1f32 = extract_subvector 0x23434a0, 0x2348320 [ID=0] Scalarize node result 0: 0x2348220: v1f32 = extract_subvector 0x23434a0, 0x23466e0 [ID=0] Split node result: 0x23469e0: v4f32 = extract_subvector 0x23435a0, 0x23466e0 [ID=0] Split node operand: 0x2346be0: v4i1 = setcc 0x23467e0, 0x23469e0, 0x23436a0 [ID=0] Split node...

Hi Hal, On 05/03/13 18:50, Hal Finkel wrote: > Hello, > > Working on my (currently out-of-tree) BG/Q PPC enhancements, I've run into the following problem with vector type legalization. Here's a quick example: > > Scalarize node result 0: 0x2348420: v1f32 = extract_subvector 0x23434a0, 0x2348320 [ID=0] > > Scalarize node result 0: 0x2348220: v1f32 = extract_subvector 0x23434a0, 0x23466e0 [ID=0] > > Split node result: 0x23469e0: v4f32 = extract_subvector 0x23435a0, 0x23466e0 [ID=0] > > Split node operand: 0x2346be0: v4i1 = setcc 0x23467e0, 0x23469e0, 0...

...rovide the complete DAG before and after the erroneous transformation? -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]...

...oks like the main complexity comes from the fact that the DAG which emerges from SelectionDAGBuilder::visitShuffleVector is often rather low-level. A case could probably be made for keeping more information around in the DAG, but that would require cooperation among all the backends. For now, both EXTRACT_SUBVECTORs and BUILD_VECTORs seem to be handled on ARM mainly by resorting to the stack, which often leads to rather bad code. EXTRACT_SUBVECTOR in particular should just involve ignoring one of the registers. I've put together a couple of patches to improve matters: http://www.maths.ed.ac.uk/~s0677366...

I ran into some odd code being generated today and I came across something that doesn't look quite right. In SelectionDAGBuilder::visitShuffleVector there's some code to see if we can convert the shuffle to an EXTRACT_SUBVECTOR. After computing min/max values of the mask for each operand, there's a look that looks at the ranges and determines whether an EXTRACT_SUBVECTOR can be used: for (int Input=0; Input < 2; ++Input) { if (MinRange[Input] == (int)(SrcNumElts+1) && MaxRange[Input] == -1) {...

...wrong (it's harder to confirm without hardware), so the bug is probably inert for in tree targets. Given a v4f16 instance t2, the DAG describes building a v2f16 vector from elements [0, 2]. The combine translates this to building a vector from elements [0, 0]. The problem seems to be treating extract_subvector with different constants as instances of the same value. t14: v2f16 = extract_subvector t2, Constant:i32<2> t15: f16 = extract_vector_elt t14, Constant:i32<0> t16: v2f16 = extract_subvector t2, Constant:i32<0> t17: f16 = extract_vector_elt t16, Constant:i32<0> t9: v2f...

Hi, I am a little unsure about the semantics of the ShuffleKind SK_ExtractSubvector. It seems a subvector is to be extracted, starting from a given index of a given subtype. First of all, if index 0 is passed, I suppose this would mean a noop? But what about calls like the one made of LoopVectorizer for Instruction::PHI in getInstructionCost(): return

...er than complicate your implementation. In particular, you should be able to introduce a new [V]CONCAT_VECTOR node, which takes two input vectors and yields an output vector that has length equal to the sum of the input vectors. Likewise, instead of the extract_element hack, we should have an EXTRACT_SUBVECTOR node of some sort. Since no target support these nodes, they would all be expanded by legalize. Note that this change is logically independent of the rest of your change, so you could do this on mainline, as a first step to getting the bigger change in. > While my original patch made the...

Hello, Here's a quick update on where I'm at with the pre-legalize vector changes I'm working on. I hope to have an updated patch ready to a few days, assuming I don't get too busy with other projects going on. Here are some of the issues I've come across so far. Putting the table for extended ValueTypes in SelectionDAG seems quite involved. There are a lot of places that use

...ontradiction found in node > vector_shuffle! > > Well, it's right!  So how do I express this kind of thing?  Since LLVM 2.5 > shufflevector supports creating a vector of a difference size than the > inputs.  Which is exactly what we need for VEXTRACTF128 and VINSERTF128. Perhaps EXTRACT_SUBVECTOR would be more appropriate here? -Eli

...1, 2, 3, 4, 5, 6, 7,0, 1, 2, 3, 4, 5, 6, 7}); if (OnlyUsesV1 || isShuffleEquivalent(V1, V2, Mask, {0, 1, 2, 3, 4, 5, 6, 7, 12, 13, 14, 15,16,17,18,19})) { MVT SubVT = MVT::getVectorVT(VT.getVectorElementType(), 16); SDValue LoV = DAG.getNode(ISD::EXTRACT_SUBVECTOR, DL, SubVT, V1, DAG.getIntPtrConstant(0, DL)); SDValue HiV = DAG.getNode(ISD::EXTRACT_SUBVECTOR, DL, SubVT, OnlyUsesV1 ? V1 : V2, DAG.getIntPtrConstant(0, DL)); return DAG.getNode(ISD::CONCAT_VECTORS,...

The AVX saga continues. I am attempting to write a pattern for VEXTRACTF128 but am having some problems. My attempt looks something like this: defm EXTRACTF128 : avx_fp_extract_vector_osta_node_mri_256<0x19, MRMDestReg, MRMDestMem, "extractf128", undef, X86f32, X86i32i8, // rr [(set VR128:$dst,

On 2017-01-20 14:31, Hal Finkel wrote: > > On 01/20/2017 06:11 AM, Jonas Paulsson via llvm-dev wrote: >> Hi, >> >> I wonder why getScalarizationOverhead() does not take into account >> the number of operands of the instruction? This should influence the >> number of extracts needed, so instead of >> >> Scalarization cost = NumEls * (insert +

...nd to custom-lower that case. >> > > Attached is a more complete version, including the simplification of > LegalizeDAG and the fixes for UINT_TO_FP and FP_TO_UINT on x86. It > passes regression tests except for one failure due to a missing > implementation of legalization for EXTRACT_SUBVECTOR where both types > are legal. Should it be named something other than LegalizeVectors then, since it handles more than just vectors? Perhaps something like LegalizeOpsNeedingNewTypes? I haven't looked into details, but I think the approach in the patch looks reasonable. Adding yet another...

...syntax; DAGCombiner could easily be made a lot more clever about cases like this. For example, before legalization, we can transform an INSERT_VECTOR_ELT inserting an element into a constant vector or a SCALAR_TO_VECTOR into a BUILD_VECTOR, and we can transform BUILD_VECTOR into CONCAT_VECTORS or EXTRACT_SUBVECTOR for relevant cases. We can also make the lowering significantly more clever about dealing with insertelement. If what we currently have isn't sufficient, I think the first step is to extend VECTOR_SHUFFLE to be more flexible, and implement the relevant combines to make that effective. I don&...

...i32 undef> %a1 = shufflevector <12 x float> %a, <12 x float> undef, <4 x i32> <i32 4, i32 5, i32 6, i32 undef> %a2 = shufflevector <12 x float> %a, <12 x float> undef, <4 x i32> <i32 8, i32 9, i32 10, i32 undef> ; t17: v4f32 = EXTRACT_SUBVECTOR t15, 0 ; t18: v4f32 = EXTRACT_SUBVECTOR t15, 4 ; t19: v4f32 = EXTRACT_SUBVECTOR t15, 8 The CONCAT_VECTORs will be cancelled out by the EXTRACT_SUBVECTOR generated for the first set of shufflevector. So the argument registers will be forwarded directly to the adds. Similarly on the return p...

Thank you Craig for explanation. Could be the same algorithm used for custom legalizing given node in LowerOperation and ReplaceNodeResults in case results and inputs of the node are illegal? Or actually such situation is impossible and for given node either LowerOperation or ReplaceNodeResults can be only called? Przemek wt., 28 sty 2020, 18:48 użytkownik Craig Topper <craig.topper at

...node is incompatible with scalable vectors because we don't know how many scalars it will takes to fill one. All common code using this node has either been rewritten or bypassed. ## *ISD::ELEMENT_COUNT* {#isdelementcount} `ELEMENT_COUNT(TYPE)` See [*elementcount*](#elementcount). ## *ISD::EXTRACT_SUBVECTOR* {#isdextractsubvector} `EXTRACT_SUBVECTOR(VECTOR, IDX)` Usage of this node is typically linked to legalization where it's used to split vectors. The index parameter is often absolute and proportional to the input vector's element count. For scalable vectors an absolute index makes littl...

Hello, I have a kernel that's swizzling a vector inside a loop. The vector was created before the loop. The first node in the dag is an extract subvector which calls into SplitVectorOp. The issue is that the node passed to it comes from a CopyFromReg and SplitVectorOp doesn't know what to do. Is there a reason why SplitVectorOp doesn't handle CopyFromReg nodes? If not, can I submit a

Hi Javier, > I have a kernel that's swizzling a vector inside a loop. The vector was > created before the loop. The first node in the dag is an extract subvector > which calls into SplitVectorOp. The issue is that the node passed to it > comes from a CopyFromReg and SplitVectorOp doesn't know what to do. Is > there a reason why SplitVectorOp doesn't handle CopyFromReg