search for: v4i8

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

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 promoted to v4i32 but this doesn't happen either. Can anyone provide s...

...out 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) >> >> v3i8 gets widened to v4i8 and then operations get unrolled (scalarized) >>because v4i8 is not a legal type whereas v4i8 gets > >This does not sound right. v3i8 -> v4i8 is okay. But the next step >should be v4i8 -> v4i32. The operation nay be scalarized in the vector >legalization phase. What I...

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) > > v3i8 gets widened to v4i8 and then operations get unrolled (scalarized) because v4i8 is not a legal type whereas v4i8 gets This does not sound right. v3i8 -> v4i8 is okay. But the next step should be v4i8 -> v4i32. The operation nay be scalarized in the vector legalization phase. > promoted to v4i32. Why doe...

...lvm.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) >>> >>> v3i8 gets widened to v4i8 and then operations get unrolled (scalarized) >>> because v4i8 is not a legal type whereas v4i8 gets >> >> This does not sound right. v3i8 -> v4i8 is okay. But the next step >> should be v4i8 -> v4i32. The operation nay be scalarized in the vector >> legal...

...Pop > Sent: Tuesday, June 19, 2012 3:39 PM > To: llvmdev at cs.uiuc.edu > Subject: [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_...

If v4i8 is a legal type then getTypeToPromoteTo should return the pair v4i8 and 'legal'. This looks like the root of the problem. -----Original Message----- From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Monday, July 30, 2012 22:10 To: Rotem, Nadav; Developers Mailing List Subject:...

v4i8 itself is a legal type, just not on the 'AND' operation. So there seems to be multiple problems here. 1) PromoteVectorOp doesn't handle the case where the types are not the same size, this occurs because #2 2) getTypeToPromoteTo doesn't actual check to see if the type it should pro...

...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) v3i8 gets widened to v4i8 and then operations get unrolled (scalarized) because v4i8 is not a legal type whereas v4i8 gets This does not sound right. v3i8 -> v4i8 is okay. But the next step should be v4i8 -> v4i32. The operation nay be scalarized in the vector legalization phase. What I'm looking at is a v3i8...

...ze as the LHS SDValue. This causes a split on the LHS side to work correctly, but then it fails instruction selection because of Other. I have not been able to figure out how to split the MVT::Other node yet, any idea how to do this? Instruction selection fails because it cannot match the pattern: v4i8 = sign_extend_inreg <v4i8 node>, <Other node(v8i8 VTSDNode)> The reason being my initial implementation based on the advice given takes as input: v8i8 = sign_extend_inreg <v8i8 node>, <Other node(v8i8 VTSDNode)> and generates two: v4i8 = sign_extend_inreg <v4i8 node>,...

...; <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) v3i8 gets widened to v4i8 and then operations get unrolled (scalarized) because v4i8 is not a legal type whereas v4i8 gets This does not sound right. v3i8 -> v4i8 is okay. But the next step should be v4i8 -> v4i32. The operation nay be scalarized in the vector legalization phase. What I'm looking at is a v3i8...

.../Type.cpp always returns false when it checks whether an integer can be bitcast to a vector or vice versa. For example, (i32 => v2i16) or (v2i16 => i32) is false. But it seems that it returns true if it is checking conversion between two vector types which have the same size. For example, (v4i8 => v2i16) would return true. What is the rationale behind this? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120702/5c2d0e32/attachment.html>

Thanks Eli, I'll see if I can get something working and submit a patch. Micah -----Original Message----- From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Wednesday, December 09, 2009 11:18 PM To: Villmow, Micah Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] SplitVecRes with SIGN_EXTEND_INREG unsupported On Wed, Dec 9, 2009 at 8:40 PM, Villmow, Micah <Micah.Villmow at

...finition of bitcast, yes, this is currently the definition. That canLoslesslyBitCastTo returns false for bitcast of i32 to <2 x i16> is probably just an oversight. Please feel free to send in a patch fixing it. Ciao, Duncan. > > > I am trying to change all vector types (v2i16 and v4i8) in > include/llvm/IntrinsicsMips.td to i32, but I can't do that because the code in > CodeGenFunction::EmitBuiltinExpr (in clang/CGBuiltin.cpp) raises an assertion > when it calls Type::canLoslesslyBitCastTo to check whether conversion between > v2i16 (or v4i8) and i32 is legal. &g...

...his mean that the following instruction %dst = bitcast i32 %src to v2i16 is equivalent to the following sequence of instructions (which I think is lossless)? store i32 %src, i32* %ptr %ptr2 = bitcast i32* %ptr to v2i16* %dst = load v2i16* %ptr2 I am trying to change all vector types (v2i16 and v4i8) in include/llvm/IntrinsicsMips.td to i32, but I can't do that because the code in CodeGenFunction::EmitBuiltinExpr (in clang/CGBuiltin.cpp) raises an assertion when it calls Type::canLoslesslyBitCastTo to check whether conversion between v2i16 (or v4i8) and i32 is legal. To work around this p...

...lse Operands[j] = Op.getOperand(j); } Op = DAG.getNode(Op.getOpcode(), dl, NVT, &Operands[0], Operands.size()); return DAG.getNode(ISD::BITCAST, dl, VT, Op); } The input Op is <4 x i8> = and <4 x i8>, <4 x i8>. The result of TLI.getTypeToPromoteTo(ISD::AND, MVT::v4i8) is MVT::v2i32; The reason why this occurs is: // See if this has an explicit type specified. std::map<std::pair<unsigned, MVT::SimpleValueType>, MVT::SimpleValueType>::const_iterator PTTI = PromoteToType.find(std::make_pair(Op, VT.getSimpleVT().SimpleTy)); i...

...the definition. That canLoslesslyBitCastTo returns > false for bitcast of i32 to <2 x i16> is probably just an oversight. > Please > feel free to send in a patch fixing it. > > Ciao, Duncan. > > > > > > > I am trying to change all vector types (v2i16 and v4i8) in > > include/llvm/IntrinsicsMips.td to i32, but I can't do that because the > code in > > CodeGenFunction::EmitBuiltinExpr (in clang/CGBuiltin.cpp) raises an > assertion > > when it calls Type::canLoslesslyBitCastTo to check whether conversion > between > > v...

Notice that PromoteVectorOp is called after the type legalization legalized all of the types in the program. It legalizes the *operations*, not the types. So, you should only see legal types (Legal types are types that fit into your registers). So, if your target has v2i32, I suspect that v4i8 is an illegal because it has a different size. -----Original Message----- From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Monday, July 30, 2012 21:26 To: Rotem, Nadav; Developers Mailing List Subject: RE: Vector promotion broken for <2 x [i8|i16]> Hrmm.... PromoteVectorOp d...

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 to 2xv4i16) Is there a way to ach...

...terns possible. In order to enable vector-select we needed to make some changes to the LLVM type-legalizer. The '-promote-elements' flag changes the way illegal vectors are legalized. Currently, the default legalization algorithm widens the number of elements in a vector. So, the vector v4i8 would be converted to v16i8. Using the 'promote-element' flag, the legalizer would first try to widen each element. So, the vector v4i8 would be converted to v4i32. Overall this is a good idea because the instruction set is usually more complete for the 'common' element type. This c...