search for: concat_vector

...m ISD node, e.g. MyTargetISD::MyLSHR, with the same type as the general ISD::LSHR. This custom node will then be ignored by the generic DAGCombiner. Convert ISD::LSHR to MyTargetISD::MyLSHR in DAGCombine, optimise it as you see fit, convert it back or lower it directly. I've done this for ISD::CONCAT_VECTORS to avoid an inconvenient conversion to ISD::BUILD_VECTOR. This looks a bit hacky though. I'll watch with interest for a more idiomatic solution. Cheers > > > > On May 15, 2017, at 07:54, vivek pandya via llvm-dev < > > llvm-dev at lists.llvm.org> wrote: > > &gt...

...ype().getVectorElementType() == Op.getValueType().getVectorElementType() && 2*Lo.getValueType().getVectorNumElements() == Op.getValueType().getVectorNumElements() && Hi.getValueType() == Lo.getValueType() && "Invalid type for split vector"' failed. The illegal CONCAT_VECTOR node is created from LegalizeVectorTypes.cpp DAGTypeLegalizer::GenWidenVectorLoads() I saw that this code comes from your commit 112171 this is the reduced test define void @add18i16(<18 x i16>* nocapture sret %ret, <18 x i16>* %bp) nounwind { %b = load <18 x i16>* %bp, align...

...on it, I do remember that. I'd file that into a category of "evil hacks", not something that we really want to support. To me, I think it would be much better to fix this directly, rather 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 lega...

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

...nding the IL-level 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 t...

Hi, We are now about halfway between the 3.4 and 3.5 releases, and I would like to start preparing for a 3.4.1 release. Here is my proposed release schedule: Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch. April 9 - April 18: Testing Phase April 18: 3.4.1 Release How you can help: - If you have any bug fixes you think should be included to 3.4.1, send me an

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

...gt; %c2.w, <12 x i32> <i32 0, i32 1, i32 2, i32 undef, i32 4, i32 5, i32 6, i32 undef, i32 8, i32 9, i32 10, i32 undef > ret <12 x float> %c } Then during SDAG building, the arguments are split to map to ABI argument registers and a CONCAT_VECTOR is used to recreate the original un-split value (SDAG code in comments): define <12 x float> split_vec(4) @f(<12 x float> split_vec(4) %a, <12 x float> split_vec(4) %b) { ; Register:v4f32 %0, %1, %2 Register:v4f32 %3, %4, %5 ; t0: ch...

Hi, The current definition of shuffle vector is <result> = shufflevector <n x <ty>> <v1>, <n x <ty>> <v2>, <n x i32> <mask> ; yields <n x <ty>> The first two operands of a 'shufflevector' instruction are vectors with types that match each other and types that match the result of the instruction. The third

On Jan 6, 2012, at 5:08 PM, Chris Lattner wrote: >>> >>> It's very like SSA construction, but must make provision >>> testing anti dependences. I had planned to use dominance frontiers to >>> guide placement of phi nodes, as usual. >> >> Ok, in that case, please check out include/llvm/Transforms/Utils/SSAUpdater.h, >> which is the

...RINSIC_VOID: + case ISD::CopyToReg: + case ISD::CopyFromReg: + case ISD::AssertSext: + case ISD::AssertZext: + // Node cannot be illegal if types are legal + break; + case ISD::BUILD_VECTOR: + case ISD::INSERT_VECTOR_ELT: + case ISD::EXTRACT_VECTOR_ELT: + case ISD::CONCAT_VECTORS: + case ISD::EXTRACT_SUBVECTOR: + case ISD::VECTOR_SHUFFLE: + case ISD::SCALAR_TO_VECTOR: + case ISD::BIT_CONVERT: + case ISD::LOAD: + case ISD::STORE: + // These are intentionally not handled here; the point of this is to + // eliminate illegal operations that could po...

.... I'd file that into a > category of "evil hacks", not something that we really want to support. > To me, I think it would be much better to fix this directly, rather 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...

...XTRACT_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, DL, VT, LoV, HiV); } assert(WidenedMask.size() == 16); // See if this is an insertion of the lower 128-bits of V2 into V1. bool IsInsert = true; int V2Index = -1; for (int i = 0; i < 16; ++i) { assert(WidenedMask[i] >= -1); if (WidenedMask[i] < 0) continue;...

...RINSIC_VOID: + case ISD::CopyToReg: + case ISD::CopyFromReg: + case ISD::AssertSext: + case ISD::AssertZext: + // Node cannot be illegal if types are legal + break; + case ISD::BUILD_VECTOR: + case ISD::INSERT_VECTOR_ELT: + case ISD::EXTRACT_VECTOR_ELT: + case ISD::CONCAT_VECTORS: + case ISD::EXTRACT_SUBVECTOR: + case ISD::VECTOR_SHUFFLE: + case ISD::SCALAR_TO_VECTOR: + case ISD::BIT_CONVERT: + case ISD::LOAD: + case ISD::STORE: + // These are intentionally not handled here; the point of this is to + // eliminate illegal operations that could po...

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...RINSIC_VOID: + case ISD::CopyToReg: + case ISD::CopyFromReg: + case ISD::AssertSext: + case ISD::AssertZext: + // Node cannot be illegal if types are legal + break; + case ISD::BUILD_VECTOR: + case ISD::INSERT_VECTOR_ELT: + case ISD::EXTRACT_VECTOR_ELT: + case ISD::CONCAT_VECTORS: + case ISD::EXTRACT_SUBVECTOR: + case ISD::VECTOR_SHUFFLE: + case ISD::SCALAR_TO_VECTOR: + case ISD::BIT_CONVERT: + case ISD::LOAD: + case ISD::STORE: + // These are intentionally not handled here; the point of this is to + // eliminate illegal operations that could po...

...ent fixed shuffle. So code that wants to handle both can pretend they're canonicalized, and code that handles fixed shuffles won't be disrupted. In SelectionDAG, shuffles aren't really unified the same way they are in IR. I think we map onto existing operations where they make sense (CONCAT_VECTORS and EXTRACT_SUBVECTOR). For scalable zip/unzip, I haven't really thought deeply about it; it probably makes sense to change SHUFFLE_VECTOR's shuffle mask to use ShuffleMask like IR, but that probably doesn't have a big impact either way. -Eli

Currently, for scalable vectors, only splat shuffles are allowed; we're considering allowing more different kinds of shuffles. The issue is, essentially, that a shuffle mask is a simple list of integers, and that isn't enough to express a scalable operation. For example, concatenating two fixed-length vectors currently looks like this: shufflevector <2 x i32> %v1, <2 x i32>

In the spirit of the (long-term) intent to migrate away from the SelectionDAG framework, it is desirable to implement legalization passes as discrete passes. Attached is a patch which implements the beginning of a new type legalization pass, to help motivate discussion. Is LLVM IR the right level for this? The main alternative approach that's been discussed is to do FastISel to a