search for: v2i1

...466e0 [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 result: 0x2348620: v2f32 = extract_subvector 0x23435a0, 0x2346de0 [ID=0] Widen node result 0: 0x2348820: v2i1 = setcc 0x2346ee0, 0x2348620, 0x23436a0 [ID=0] llc: lib/CodeGen/SelectionDAG/LegalizeTypes.h:599: llvm::SDValue llvm::DAGTypeLegalizer::GetWidenedVector(llvm::SDValue): Assertion `WidenedOp.getNode() && "Operand wasn't widened?"' failed. The problem is essentially the fo...

...> The problem is essentially the following: there are no vector f32 types (yet), so the <v4i1> = setcc <v4f32> node needs to be split and scalarized. The operand splitting seems to start correctly, but because <v4i1> is itself a legal type, after splitting the node into <v2i1> = setcc <v2f32>, the process becomes confused. The operands are again split (as they should be), but it tries to widen the <v2i1> result back to <v4i1> (thus hitting the operand assertion). > In some sense, the problem is that DAGTypeLegalizer::run decides what to do solely...

...is essentially the following: there are no vector f32 > types (yet), so the <v4i1> = setcc <v4f32> node needs to be split > and scalarized. The operand splitting seems to start correctly, but > because <v4i1> is itself a legal type, after splitting the node into > <v2i1> = setcc <v2f32>, the process becomes confused. The operands > are again split (as they should be), but it tries to widen the > <v2i1> result back to <v4i1> (thus hitting the operand assertion). > > In some sense, the problem is that DAGTypeLegalizer::run decides w...

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> %1 = extractelement &...

...sult: 0x23469e0: v4f32 = extract_subvector 0x23435a0, 0x23466e0 [ID=0] > > Split node operand: 0x2346be0: v4i1 = setcc 0x23467e0, 0x23469e0, 0x23436a0 [ID=0] > > Split node result: 0x2348620: v2f32 = extract_subvector 0x23435a0, 0x2346de0 [ID=0] > > Widen node result 0: 0x2348820: v2i1 = setcc 0x2346ee0, 0x2348620, 0x23436a0 [ID=0] > > llc: lib/CodeGen/SelectionDAG/LegalizeTypes.h:599: llvm::SDValue llvm::DAGTypeLegalizer::GetWidenedVector(llvm::SDValue): Assertion `WidenedOp.getNode() && "Operand wasn't widened?"' failed. > > The problem is...

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

...AGTypeLegalizer::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<mailto: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 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> %1 = extracteleme...

...AGTypeLegalizer::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<mailto: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 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> %1 = extracteleme...

...es_LOAD in LegalizeVectorTypes.cpp. I noticed that it is using getSizeInBits()/8 to compute IncrementSize, which is the offset for the load of second half of the vector. I have a situation where the frontend is producing load for a <2 x i1> type, and the architecture has i1 registers (but not v2i1 registers). The store size of i1 is 8 bits (the size returned by getStoreSizeInBits()). When SplitVecRes_LOAD is called, because it is using getSizeInBits()/8, the offset for the second half is zero, so it ends up using the same i1 value for both the halves. Is this a bug, or am I missing something...

Hello, I'm working on support for the SIMD instruction set on our new BG/Q supercomputer. This instruction set is v4f64 (with the exception of some int <-> fp conversions, floating-point only). The vectorized comparisons, logical operations and selects also exclusively use floating-point inputs. For those inputs that are logically vectors of booleans the system uses the following