search for: legalizevectortype

...with similar error under same platform? Thanks a lot. ..... ..... `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' referenced in section `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' of /home/ktian/llvm/llvm-2.5/Release/lib/libLLVMSelectionDAG.a(LegalizeVectorTypes.o): defined in discarded section `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' of /home/ktian/llvm/llvm-2.5/Release/lib/libLLVMSelectionDAG.a(LegalizeVectorTypes.o) `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' referenced in section `.gnu.lin...

...call is "SVML" (which is currently string match against "__svml" prefix in my local workspace). If higher VF is not forced, cost model will likely favor lower VF. Functionally correct, but obviously not an ideal solution. Here are a few ideas I thought about: 1) Standard LegalizeVectorType() in CodeGen/SelectionDAG doesn't seem to work. We could define a generic ISD::VECLIB and try to split into two or more VECLIB nodes, but at that moment we lost the information about which function to call. We can't define ISD opcode per function. There will be too many libm entries to deal...

I have code that is generating sign extend in reg on a v8i32, but the backend does not support this data type. This then asserts in LegalizeVectorTypes.cpp:389 because there is no function to split this vector into smaller sizes. Would a correct solution be to add this case so to trigger the SplitVecRes_BinaryOp function? This asserts on both my backend and x86 and TOT does not seem to have any code to handle this. Thanks, Micah -------...

...r when I try to build llvm with gcc-4.2.4 with ENABLE_OPTIMIZED=1: `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' referenced in section `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' of /pkg/build/llvm/llvm-obj/Release/lib/libLLVMSelectionDAG.a(LegalizeVectorTypes.o): defined in discarded section `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' of /pkg/build/llvm/llvm-obj/Release/lib/libLLVMSelectionDAG.a(LegalizeVectorTypes.o) collect2: ld returned 1 exit status make[2]: *** [/pkg/build/llvm/llvm-obj/Release/lib/libLTO.so] Error 1...

...call is "SVML" (which is currently string match against "__svml" prefix in my local workspace). If higher VF is not forced, cost model will likely favor lower VF. Functionally correct, but obviously not an ideal solution. Here are a few ideas I thought about: 1) Standard LegalizeVectorType() in CodeGen/SelectionDAG doesn't seem to work. We could define a generic ISD::VECLIB and try to split into two or more VECLIB nodes, but at that moment we lost the information about which function to call. We can't define ISD opcode per function. There will be too many libm entries to deal...

On Wed, Dec 9, 2009 at 8:40 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I have code that is generating sign extend in reg on a v8i32, but the > backend does not support this data type.  This then asserts in > LegalizeVectorTypes.cpp:389 because there is no function to split this > vector into smaller sizes. Would a correct solution be to add this case so > to trigger the SplitVecRes_BinaryOp function? SIGN_EXTEND_INREG isn't a binary operation; the correct expansion is expanding the first operand the same way S...

I was going through the function DAGTypeLegalizer::SplitVecRes_LOAD in LegalizeVectorTypes.cpp. I noticed that it is using getSizeInBits()/8 to compute IncrementSize, which is the offset for the load of second half of the vector. I have a situation where the frontend is producing load for a <2 x i1> type, and the architecture has i1 registers (but not v2i1 registers). The store si...

..._svml” prefix in my local workspace). >> >> If higher VF is not forced, cost model will likely favor lower VF. >> Functionally correct, but obviously not an ideal solution. >> >> >> >> Here are a few ideas I thought about: >> >> 1) Standard LegalizeVectorType() in CodeGen/SelectionDAG doesn’t >> seem to work. We could define a generic ISD::VECLIB >> and try to split into two or more VECLIB nodes, but at that moment we >> lost the information about which function to call. >> We can’t define ISD opcode per function. There will be t...

...getValueType().getVectorElementType() && 2*Lo.getValueType().getVectorNumElements() == Op.getValueType().getVectorNumElements() && Hi.getValueType() == Lo.getValueType() && "Invalid type for split vector"' failed. The illegal CONCAT_VECTOR node is created from LegalizeVectorTypes.cpp DAGTypeLegalizer::GenWidenVectorLoads() I saw that this code comes from your commit 112171 this is the reduced test define void @add18i16(<18 x i16>* nocapture sret %ret, <18 x i16>* %bp) nounwind { %b = load <18 x i16>* %bp, align 16 %x = add <18 x i16> zeroiniti...

Hello, Scott > Yes, so I have read -- which is why I initially installed gcc-4.2.4. > My original post was looking for help on how to use gcc-4.2.4. Some > suggestions were made, but I was not able to get everything built. It > seems that despite attempting to configure with everything pointing to > gcc-4.2.4 (and not the system gcc 4.1.2), at some point in the build, >

...h gcc-4.2.4 with > ENABLE_OPTIMIZED=1: > > `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' > referenced in section > `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' > of /pkg/build/llvm/llvm-obj/Release/lib/libLLVMSelectionDAG.a(LegalizeVectorTypes.o): > defined in discarded section > `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' > of /pkg/build/llvm/llvm-obj/Release/lib/libLLVMSelectionDAG.a(LegalizeVectorTypes.o) > collect2: ld returned 1 exit status > make[2]: *** [/pkg/build/llvm/llvm-obj/Releas...

On Wed, May 6, 2009 at 12:51 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Even if you'll succeed, most probably LLVM will be miscompiled. gcc > 4.1.2 is known buggy: http://llvm.org/docs/GettingStarted.html#brokengcc > Yes, so I have read -- which is why I initially installed gcc-4.2.4. My original post was looking for help on how to use gcc-4.2.4. Some

...rrently > string match against “__svml” prefix in my local workspace). > > If higher VF is not forced, cost model will likely favor lower VF. > Functionally correct, but obviously not an ideal solution. > > > > Here are a few ideas I thought about: > > 1) Standard LegalizeVectorType() in CodeGen/SelectionDAG doesn’t > seem to work. We could define a generic ISD::VECLIB > and try to split into two or more VECLIB nodes, but at that moment we lost > the information about which function to call. > We can’t define ISD opcode per function. There will be too many libm &gt...

...t: Re: [LLVMdev] SplitVecRes with SIGN_EXTEND_INREG unsupported On Wed, Dec 9, 2009 at 8:40 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I have code that is generating sign extend in reg on a v8i32, but the > backend does not support this data type.  This then asserts in > LegalizeVectorTypes.cpp:389 because there is no function to split this > vector into smaller sizes. Would a correct solution be to add this case so > to trigger the SplitVecRes_BinaryOp function? SIGN_EXTEND_INREG isn't a binary operation; the correct expansion is expanding the first operand the same way S...

...> If higher VF is not forced, cost model will likely favor > lower VF. Functionally correct, but obviously not an ideal > solution. > >   > > Here are a few ideas I thought about: > > 1)      Standard LegalizeVectorType() in > CodeGen/SelectionDAG doesn’t seem to work. We could define > a generic ISD::VECLIB > and try to split into two or more VECLIB nodes, but at > that moment we lost the information about which function > to call. >...

"Rotem, Nadav" <nadav.rotem at intel.com> writes: > I can think of two ways to represent masks in x86: sparse and > packed. In the sparse method, the masks are kept in <4 x 32bit> > registers, which are mapped to xmm registers. This is the ‘native’ way > of using masks. This argues for the sparse representation, I think. > _Sparse_ After my discussion with

...store masks. In my private branch, I added the [v4i1 .. v64i1] types. I also implemented a new type of target lowering: "PACK". This lowering packs vectors of i1s into integer registers. For example, the <4 x i1> type would get packed into the i8 type. I modified LegalizeTypes and LegalizeVectorTypes and added legalization for SETCC, XOR, OR, AND, and BUILD_VECTOR. I also changed the x86 lowering of SELECT to prevent lowering of selects with vector condition operand. Next, I am going to add new patterns for SETCC and SELECT which use i8/i16/i32/i64 as a condition value. I also plan to experi...

Hello, I started working on adding vector support for the SELECT and CMP instructions in the codegen (bugs: 3384, 1784, 2314).  Currently, the codegen scalarizes vector CMPs into multiple scalar CMPs.  It is easy to add similar scalarization support to the SELECT instruction.  However, using multiple scalar operations is slower than using vector operations. In LLVM, vector-compare operations

On Jan 6, 2012, at 5:08 PM, Chris Lattner wrote: >>> >>> It's very like SSA construction, but must make provision >>> testing anti dependences. I had planned to use dominance frontiers to >>> guide placement of phi nodes, as usual. >> >> Ok, in that case, please check out include/llvm/Transforms/Utils/SSAUpdater.h, >> which is the

...ith SIGN_EXTEND_INREG unsupported > > On Wed, Dec 9, 2009 at 8:40 PM, Villmow, Micah <Micah.Villmow at amd.com> > wrote: > > I have code that is generating sign extend in reg on a v8i32, but the > > backend does not support this data type.  This then asserts in > > LegalizeVectorTypes.cpp:389 because there is no function to split > this > > vector into smaller sizes. Would a correct solution be to add this > case so > > to trigger the SplitVecRes_BinaryOp function? > > SIGN_EXTEND_INREG isn't a binary operation; the correct expansion is > expandi...