search for: v16i8

I have the following selection DAG: SelectionDAG has 9 nodes: t0: ch = EntryToken t2: i64,ch = CopyFromReg t0, Register:i64 %vreg0 t16: i32,ch = load<LD1[%ptr](tbaa=<0x10023c9f448>), anyext from i8> t0, t2, undef:i64 t15: v16i8 = BUILD_VECTOR t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16 t11: ch,glue = CopyToReg t0, Register:v16i8 %V2, t15 t12: ch = PPCISD::RET_FLAG t11, Register:v16i8 %V2, t11:1 and the following pattern that I'd like to match: def ScalarLoads { dag Li8 = (i3...

<Copied Cong> Thanks Elena. Mostly I was interested in why such a high cost 30 kept for TRUNCATE v16i32 to v16i8 in SSE41. Looking at the code it appears like TRUNCATE v16i32 to v16i8 in SSE41 is very expensive vs SSE2. I feel this number should be same/close to the cost mentioned for same operation in SSE2ConversionTbl. Below patch from Cong Hou reduce cost for same operation in SSE2 mode. http://reviews.ll...

PPC Altivec supports vector type v16i8 (and others) where the element type is not legal (in llvm's implementation). When we have a BUILD_VECTOR of these types with constant elements, LegalizeTypes first promotes the element types to i32, then builds a constant pool entry of type v16i32. This is wrong. I can fix it by trun...

...ern to represent some vector operations in the DAG. Stuff like andx/orx operations where elements of a vector are anded/ored together. My approach thus far has been to extract the sub elements of the vector and and/or those elements. This is ok for 4 vectors of i32s, but becomes cumbersome for v16i8s. Example instruction: andx $dst $v1 Pattern: [(set RC:$dst, (and (i32 (vector_extract(vt VC:$src), 0 ) ), (and (i32 (vector_extract(vt VC:$src), 1 ) ), (and (i32 (vector_extract(vt VC:$src), 2 ) ), (i32 (vector_extract(vt VC:$src), 3 ) ) )...

Hi, I was going through the X86TTIImpl::getCastInstrCost, and got a doubt on cost calculation for TRUNCATE instruction in AVX mode. In AVX2ConversionTbl & AVXConversionTbl table there is no cost defined for TRUNCATE v16i32 to v16i8, as a fallback it goes to SSE41ConversionTbl table and there it finds cost as 30 for this operation. 30 cost for this operation looks very high. Wondering why such a high cost kept for this, any pointers to understand this will be helpful. In few cases this restricts better vectorization opportuni...

To elaborate, it is not only cumbersome writing these patterns for vectors of 16 characters (v16i8), it does not work. When I compile with this pattern for an andx operation on v16i8: /[(set RC:$dst,// // (and (i8 (vector_extract(vt VC:$src), 0 ) ), // // (and (i8 (vector_extract(vt VC:$src), 1 ) ),// // (and (i8 (vector_extract(vt VC:$src), 2 ) ),// ////(and (i8 (vector_extract(vt...

On Nov 9, 2009, at 6:11 PM, Dale Johannesen wrote: > PPC Altivec supports vector type v16i8 (and others) where the element > type is not legal (in llvm's implementation). When we have a > BUILD_VECTOR of these types with constant elements, LegalizeTypes > first promotes the element types to i32, then builds a constant pool > entry of type v16i32. This is wrong....

...looking at implementing something where I think I'd like to >> keep the original vector types. Is this behavior in the type >> legalizer something that should be changed? > > I'm not sure what behavior you're talking about... If I have a BUILD_VECTOR that creates a v16i8 type, and v16i8 is a legal type for the target that does not require any promotion or expansion, I would not expect the type legalizer to change it. But, it does. It looks at the i8 elements and decides that they need to be promoted to i32, so it changes the BUILD_VECTOR to create a v4i32...

Hi Dale, I think Bob is right: the type legalizer shouldn't be turning v16i8 into v16i32, what should happen is that the return type of the BUILD_VECTOR continues to be v16i8, but the type of the operands changes to i32, so you end up with a BUILD_VECTOR that takes 16 lots of i32, and produces a v16i8. The target then has all the info it needs to produce the best code, but...

...28 register classes which are exactly like this. Rather than adding a whole bunch of instruction selection rules to match all the possibilities. We've decided to ask the legalizer to normalize the target-independent nodes to one particular type. See X86ISelLowering.cpp: // Promote v16i8, v8i16, v4i32 load, select, and, or, xor to v2i64. for (unsigned VT = (unsigned)MVT::v16i8; VT != (unsigned) MVT::v2i64; VT++) { setOperationAction(ISD::AND, (MVT::ValueType)VT, Promote); AddPromotedToType (ISD::AND, (MVT::ValueType)VT, MVT::v2i64); ... Evan > &...

...r type legalization works. In particular, I'm looking at i8 vector types on x86 (with sse42 features) v3i8 gets widened to v4i8 and then operations get unrolled (scalarized) because v4i8 is not a legal type whereas v4i8 gets promoted to v4i32. Why doesn't v3i8 (or even v4i8) get widened to v16i8? Alternatively, v3i8 could be widened to v4i8 then promoted to v4i32 but this doesn't happen either. Can anyone provide some insight into why vector type legalization works the way it does? Thanks, paul

...bd instruction. One variant takes two XMM registers, while another has a 32-bit memory location as source operand. The latter is quite interesting if you know you're reading from memory anyway, and if it's not 16-byte aligned. It looks like LLVM's Intrinsic::x86_sse41_pmovsxbd expects a v16i8 as source operand though. So how do I achieve using the variant taking a memory operand? Thanks a bunch, Nicolas Capens -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080801/721d443e/attachment.html...

Hi All, I'm working on a back end for an architecture that makes use of multi- typed register classes. def MR: RegisterClass<"namespace", [type1, type2, ... ], ... > When running some preliminary tests I found that the instruction selector refused to select certain ops (specifically stores) for some instructions when the operand type wasn't the first type for the

On Mon, Feb 2, 2009 at 11:31 AM, Bob Wilson <bob.wilson at apple.com> wrote: > LLVM's type legalizer is changing the types of BUILD_VECTORs in a way > that seems wrong to me, but I'm not sure if this is a bug or if some > targets may be relying on it. > > On a 32-bit target, the default action for legalizing i8 and i16 types > is to promote them. This isn't

Hi When a reduction instruction is vectorized in a loop, it will be turned into an instruction with vector operands of the same operation type. This new instruction has a special property that can give us more flexibility during instruction selection later: this operation is valid as long as the reduction of all elements of the result vector is identical to the reduction of all elements of its

...e debug dump shows "Widen node result 0: 0x563dd20: v3i8 = add 0x563d820, 0x563dc20 [ORD=5] [ID=0]". To me it doesn't look like it's possible to both widen and promote an operation.. Paul > >> promoted to v4i32. Why doesn't v3i8 (or even v4i8) get widened to >>v16i8? Alternatively, v3i8 could be widened to v4i8 then promoted to >>v4i32 but this doesn't happen either. >> >> Can anyone provide some insight into why vector type legalization works >>the way it does? >> >> Thanks, >> paul >> >> __________...

Hi Dale, > PPC Altivec supports vector type v16i8 (and others) where the element > type is not legal (in llvm's implementation). When we have a > BUILD_VECTOR of these types with constant elements, LegalizeTypes first > promotes the element types to i32, then builds a constant pool entry of > type v16i32. are you sure? I wou...

On Nov 9, 2009, at 6:33 PM, Duncan Sands wrote: > Hi Dale, > >> PPC Altivec supports vector type v16i8 (and others) where the >> element type is not legal (in llvm's implementation). When we have >> a BUILD_VECTOR of these types with constant elements, LegalizeTypes >> first promotes the element types to i32, then builds a constant >> pool entry of type v16i32. &...

Hi all, I have a bunch of new registers set up in X86RegisterInfo.td, the important part being def PR128 : RegisterClass<"X86", [i128], 128, (sequence "POI%u", 0, 7)>; def VR128 : RegisterClass<"X86", [v4f32, v2f64, v16i8, v8i16, v4i32, v2i64], 128, (add PR128, FR32)>; I have an entry in X86ISelLowering.cpp: addRegisterClass(MVT::i128, &X86::PR128RegClass); and in findRepresentativeClass(): case MVT::i128: RRC = &X86::PR128RegClass; But even though my nodes have MVT::i1...

...several allowed ValueTypes? This is useful for targets where multiple types of the same size can be held in the same registers. For example, if the target has a unified register file for Int/FP, it could have [i64, f64]. In practice, this is most useful for vector types, the X86 backend has [v16i8, v8i16, v4i32, v2i64, v4f32, v2f64]. -Chris -- http://nondot.org/sabre/ http://llvm.org/