search for: v16i8s

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

<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

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 truncating the elements back to i8 in ExpandBUILD_VECTOR. Does

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

...ector 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_e...

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. I can

On Feb 2, 2009, at 1:51 PM, Eli Friedman wrote: > 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

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 needs to be careful

On Feb 12, 2007, at 1:41 AM, Christopher Lamb wrote: > > selector refused to select certain ops (specifically stores) for some > instructions when the operand type wasn't the first type for the > register class. After some digging around I seem to have solved the > problem by creating bitconvert patterns between the types in the > register class like the following: > >

Hi, I am trying to understand how vector 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

Hi all, I was wondering how to use variations of intrinsic functions that take a memory operand. Take for example the SSE4.1 pmovsxbd 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

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

Hi Nadav, On 2013-08-12 12:59 PM, "Nadav Rotem" <nrotem at apple.com> wrote: >Hi Paul, > >You can read about it here: >http://blog.llvm.org/2011/12/llvm-31-vector-changes.html > >> Hi, >> >> I am trying to understand how vector type legalization works. In >>particular, I'm looking at i8 vector types on x86 (with sse42 features)

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 would expect it to build v4i32. Ciao, Duncan.

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

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

On Sat, 13 May 2006, Vladimir Prus wrote: > I'm porting some existing code of mine to CVS HEAD, and don't understand > something about new RegisterClass TableGen definition: > > class RegisterClass<string namespace, list<ValueType> regTypes,........ > { > ..... > string Namespace = namespace; > > What is this "namespace"