search for: v4i16

Hi, I was wondering if there is a way to specify macros to help shorten rewriting patterns like these: def : Pat <(v4i8 (mul (v4i8 IntRegs:$a), (v4i8 IntRegs:$b))), (v4i8 (VTRUNEHB (v4i16 (VTRUNEWH (v2i32 (VMPYH (v2i16 (EXTRACT_SUBREG (v4i16 (VSXTBH (v4i8 IntRegs:$a))), subreg_hireg)), (v2i16 (EXTRACT_SUBREG (v4i16 (VSXTBH (v4i8 IntRegs:$b))), subreg_hireg)))), (v2i32 (VMPYH (v2i16 (EXTRACT_SUBREG (v4i...

I have two patterns in tablegen that do look like the exact same thing: Pat 1) def MOV_v4i16 : ILFormat<IL_OP_MOV, (outs GPRV4I16:$dst), (ins i16imm:$val), asm, [(set GPRV4I16:$dst, (build_vector (i16 imm:$val)))]>; Pat 2) def v4i16imm : Operand<v4i16>; def MOV_v4i16 : ILFormat<IL_OP_MOV, (outs GPRV4I16:$dst), (ins v4i16imm:$val), asm, [(set GPRV4I1...

...: [LLVMdev] How to define macros in a tablegen file? > > Hi, > > I was wondering if there is a way to specify macros to help shorten > rewriting patterns like these: > > def : Pat <(v4i8 (mul (v4i8 IntRegs:$a), (v4i8 IntRegs:$b))), > (v4i8 > (VTRUNEHB > (v4i16 > (VTRUNEWH > (v2i32 > (VMPYH > (v2i16 > (EXTRACT_SUBREG (v4i16 (VSXTBH (v4i8 IntRegs:$a))), > subreg_hireg)), > (v2i16 > (EXTRACT_SUBREG (v4i16 (VSXTBH (v4i8 IntRegs:$b))), > subreg_hireg)))), > (v2i32 >...

Hi all, I am working on a target that has support for v4i16 vectors, and no support for v4i8 / v8i8 / v8i16 V4i8 is promoted to v4i16 which is nice V8i16 is split to 2 x v4i16 which is nice as well Now v8i8 is scalarized, which is not so nice. Ideally I would like v8i8 to be first promoted to v8i16 then split to 2xv4i16 (or split to 2xV4i8 then promoted t...

...ect behavior. If that's the case, it should definitely be fixed. Could you provide 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_v...

...regression when upgrading from LLVM 2.8 to 3.0-rc1 (LLVM 2.9 didn't support Win64 so I skipped it entirely). I found out that the performance regression is due to removing support for lowering 64-bit vector operations to MMX, and using SSE2 instead. My code uses a mix of MMX intrinsics and v4i16 operations, so it ping-pongs back and forth between MMX and SSE2 instructions in the generated code. To get more optimal code, I see three options, and I was wondering if someone could share some advice on which approach you think will work best: 1) I could use v8i16 or v4i32 instead of v4i16, b...

Hi Nicolas, > I found out that the performance regression is due to removing support > for lowering 64-bit vector operations to MMX, and using SSE2 instead. My > code uses a mix of MMX intrinsics and v4i16 operations, so it ping-pongs > back and forth between MMX and SSE2 instructions in the generated code. > > To get more optimal code, I see three options, and I was wondering if > someone could share some advice on which approach you think will work best: > 1) I could use v8i16 or v4i...

Hi, I have an issue with pattern matching. I have the following SelectionDAG: t13: i32 = extract_vector_elt t2, Constant:i64<1> That I am trying to match with the following pattern: def : Pat<(extractelt (v4i16 SingleReg:$v), 1), (SRADd1 SingleReg :$v, (i64 16))>; But for some reason the pattern does not match. It seems to be due to the fact extract_vector_elt's result type is i32 (because i16 is not a legal type on our processor), but according to the comment in ISDOpcodes.h, it is allowed for...

...c;i++) c += b; printf("%d %d %d %d\n",c[0],c[1],c[2],c[3]); return 0; } When I compile this to bytecode with clang and then invoke llc with -march=mips, everything goes fine and the code is scalarized. But when I try it on my backend, I get LLVM ERROR: Cannot select: 0xa5e2730: v4i16 = BUILD_VECTOR 0xa5e29d8, 0xa5e2378, 0xa5e21e0, 0xa5e2158 [ID=14] 0xa5e29d8: i32 = Constant<1> [ID=11] 0xa5e2378: i32 = Constant<2> [ID=10] 0xa5e21e0: i32 = Constant<3> [ID=9] 0xa5e2158: i32 = Constant<4> [ID=8] Now I've looked at the Mips backend and other back...

...; from LLVM 2.8 to 3.0-rc1 (LLVM 2.9 didn't support Win64 so I skipped it > entirely). > > I found out that the performance regression is due to removing support > for lowering 64-bit vector operations to MMX, and using SSE2 instead. My > code uses a mix of MMX intrinsics and v4i16 operations, so it ping-pongs > back and forth between MMX and SSE2 instructions in the generated code. > > To get more optimal code, I see three options, and I was wondering if > someone could share some advice on which approach you think will work best: > 1) I could use v8i16 or...

...he original vector types. Is this behavior in the type > legalizer something that should be changed? another way this could be done is to say that the operands of a BUILD_VECTOR don't have to have the same type as the element type of the built vector. Then when the type legalizer sees a v4i16 = BUILD_VECTOR(i16, i16, i16, i16) it can turn this into a v4i16 = BUILD_VECTOR(i32, i32, i32, i32) and it will be happy (all result and operand types are legal). This requires changing the definition of BUILD_VECTOR slightly. Targets will need to understand that only the bottom 16 bits of the op...

...to 3.0-rc1 (LLVM 2.9 didn't support Win64 so I skipped it >> entirely). >> >> I found out that the performance regression is due to removing support >> for lowering 64-bit vector operations to MMX, and using SSE2 instead. My >> code uses a mix of MMX intrinsics and v4i16 operations, so it ping-pongs >> back and forth between MMX and SSE2 instructions in the generated code. >> >> To get more optimal code, I see three options, and I was wondering if >> someone could share some advice on which approach you think will work best: >> 1) I co...

...> tries to replace the SDValue with itself. >> > > I think this error can only happen during type legalization, so my guess > is that you are returning a node that has an illegal type. Can you > provide more information about the node this is failing with? On my target v2i16, v4i16, v2i32, v4i32, v2f32, v4f32 are legal and all other vector types are not. Vectors of i16 are a bit special and we need to custom lower bitcasts to/from them. Therefore we do setOperationAction(ISD::BITCAST, VT, Custom); on all MVT:s, and in our target's LowerOperation/LowerBitcast we...

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. If you then have a BUILD_VECTOR to construct a legal vector type composed of i8 or i16 values, the type legalizer will

...>addAttribute(AttributeSet::FunctionIndex, Attribute::NoUnwind); DEBUG(dbgs() << "callGather: " << *callGather << "\n"); When running this code we get at stderr something like: callgather: %50 = call <4 x i16> @llvm.masked.gather.v4i16(<4 x i16*> getelementptr (i16, i16* inttoptr (i16 51 to i16*), <4 x i64> <i64 1, i64 1, i64 1, i64 1>), i32 0, <4 x i1> <i1 true, i1 true, i1 true, i1 true>, <4 x i16> undef) Also, more importantly, the resulting LLVM program will also contain this 1 gathe...

...he original vector types. Is this behavior in the type > legalizer something that should be changed? another way this could be done is to say that the operands of a BUILD_VECTOR don't have to have the same type as the element type of the built vector. Then when the type legalizer sees a v4i16 = BUILD_VECTOR(i16, i16, i16, i16) it can turn this into a v4i16 = BUILD_VECTOR(i32, i32, i32, i32) and it will be happy (all result and operand types are legal). This requires changing the definition of BUILD_VECTOR slightly. Targets will need to understand that only the bottom 16 bits of the op...

On Feb 2, 2009, at 1:22 PM, Duncan Sands wrote: > another way this could be done is to say that the operands of a > BUILD_VECTOR don't have to have the same type as the element type > of the built vector. Then when the type legalizer sees a > v4i16 = BUILD_VECTOR(i16, i16, i16, i16) it can turn this into a > v4i16 = BUILD_VECTOR(i32, i32, i32, i32) and it will be happy > (all result and operand types are legal). This requires changing > the definition of BUILD_VECTOR slightly. Targets will need to > understand that only the bott...

Hi Justin, There are some backward incompatible features of PTX; for example, special registers are redefined as v4i32 (they were v4i16) in PTX 2.0. And CUDA 4.0 was rolled out last week. I heard that some instructions are deprecated. I am not sure how stable (or unstable) PTX specification is. Do you have a rough assessment of its stability? If PTX specification is still fast evolving, I would suggest we keep up with latest spec...

...didn't support Win64 so I skipped it >>> entirely). >>> >>> I found out that the performance regression is due to removing support >>> for lowering 64-bit vector operations to MMX, and using SSE2 instead. My >>> code uses a mix of MMX intrinsics and v4i16 operations, so it ping-pongs >>> back and forth between MMX and SSE2 instructions in the generated code. >>> >>> To get more optimal code, I see three options, and I was wondering if >>> someone could share some advice on which approach you think will work best:...

...ebruary 29, 2012 2:35 AM To: Martinez, Javier E; llvmdev at cs.uiuc.edu Subject: RE: Expand vector type Hi, * Is there a way to setup LLVM to automatically convert vec3s to vec4s? Yes, if you specify v3i16 and friends as "promote" instead of "legal", llvm will promote it to a v4i16. The ARM NEON backend does this already. I'm surprised you haven't got this happening already as you mention that LLVM widens your loads to 4-element vectors... (this should happen during DAG type legalization, by the way). Cheers, James From: llvmdev-bounces at cs.uiuc.edu<mailto:llv...