similar to: [LLVMdev] vector type legalization

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

This is a bug in the implementation of WidenVecRes_Binary. On line 1546 it assumes that “Widen” is the last phase of type-legalization and we check if the result is a legal type. But actually we want to continue and promote the elements of the vector. In other cases we may want to widen (to the next power of two) and later split in half because the vector is too big. On Aug 12, 2013, at 10:46

Hi Nadav, I believe the implementation to keep on widening the vector to the next power of two must be in TargetLowering.h because that is where we decide whether to Widen the vector or not, and the size to which we widen it. In this case, we stop at 4xi8 and do not check if it is legal or not. But the comment says ‘try to widen vector elements until a legal type is found’. Also, there is a

Hi Nadav, From: Nadav Rotem <nrotem at apple.com<mailto:nrotem at apple.com>> Date: Monday, 12 August, 2013 1:59 PM To: Paul Redmond <paul.redmond at intel.com<mailto:paul.redmond at intel.com>> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>> Subject: Re: [LLVMdev] vector type legalization This is a bug in the

Hello everyone, I wanted to let everybody know that I am going to enable the support for vector-select by default later today. Details: Currently the LLVM code-generator only supports 'select' [1] instructions with a boolean condition. Vectorizing compilers, such as the Intel OpenCL Vectorizer and the GCC vectorizer often use vector-select instructions to implements masks. This change

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, great work, thanks a lot! I did not have the time to migrate our OpenCL driver to the latest trunk yet, but I followed your commits and tried out some small tests which worked as expected :). The last thing missing for us now is AVX support in the JIT, but that is a different issue. However, there is one thing I do not fully understand: what if somebody actually wants a vector of

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: RE: Vector promotion broken for <2 x [i8|i16]> v4i8 itself is a legal type, just not

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 promote to makes any sense. 3) PromoteVectorOp also doesn't handle the case where

Hrmm.... PromoteVectorOp doesn't seem to follow this at all. http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { // Vector "promotion" is basically just bitcasting and doing the operation // in a different type. For example, x86 promotes ISD::AND on v2i32 to // v1i64. EVT VT =

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

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 achieve

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

After some attempt to implement reduce-add in LLVM, I found out a easier way to detect reduce-add without introducing new IR operations. The basic idea is annotating phi node instead of add (so that it is easier to handle other reduction operations). In PHINode class, we can add a flag indicating if the phi node is a reduction one (the flag can be set in loop vectorizer for vectorized phi nodes).

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

This is the definition of BITCAST in include/llvm/CodeGen/ISDOpcodes.h: // BITCAST - This operator converts between integer, vector and FP // values, as if the value was stored to memory with one type and loaded // from the same address with the other type (or equivalently for vector // format conversions, etc). The source and result are required to have // the same bit size (e.g. f32 <->

Hi Akira, > This is the definition of BITCAST in include/llvm/CodeGen/ISDOpcodes.h: > > // BITCAST - This operator converts between integer, vector and FP > // values, as if the value was stored to memory with one type and loaded > // from the same address with the other type (or equivalently for vector > // format conversions, etc). The source and result are required to have

----- Original Message ----- > From: "Nadav Rotem" <nrotem at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Wednesday, March 6, 2013 3:40:50 PM > Subject: Re: [LLVMdev] Vector splitting vs widening > > Hi Hal, > > > > > > > The

Hi Duncan and llvm developers, The attached patch makes the function return true if the conversion is between a vector and an integer of the same size. Please review when you have time. On Tue, Jul 10, 2012 at 12:21 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Akira, > > > This is the definition of BITCAST in include/llvm/CodeGen/ISDOpcodes.h: > > > > //