search for: legalizevectortypes

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

Illustrative Example: clang -fveclib=SVML -O3 svml.c -mavx #include <math.h> void foo(double *a, int N){ int i; #pragma clang loop vectorize_width(8) for (i=0;i<N;i++){ a[i] = sin(i); } } Currently, this results in a call to <8 x double> __svml_sin8(<8 x double>) after the vectorizer. This is 8-element SVML sin() called with 8-element argument. On the surface,

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

Ashutosh, Thanks for the repy. Related earlier topic on this appears in the review of the SVML patch (@mmasten). Adding few names from there. https://reviews.llvm.org/D19544 There, I see Hal's review comment "let's start only with the directly-legal calls". Apparently, what we have right now in the trunk is "not legal enough". I'll work on the patch to stop

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

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

Adding to Ashutosh's comments, We are also interested in making LLVM generate vector math library calls that are available with glibc (version > 2.22). reference: https://sourceware.org/glibc/wiki/libmvec Using the example case given in the reference, we found there are 2 vector versions for "sin" (4 X double) with same VF namely _ZGVcN4v_sin (avx) version and _ZGVdN4v_sin

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

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

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

It may not be a full solution for the problems you're trying to solve, but I don't know why adding to include/llvm/CodeGen/RuntimeLibcalls.def is a problem in itself. Certainly, it's a mess that could be organized, especially so we're not repeating everything for each data type as we do right now. So yes, I think that would allow us to remove the VecLib mappings because we are

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

On 07/02/2018 04:33 PM, Saito, Hideki wrote: > >   > > >It may not be a full solution for the problems you're trying to solve > >   > > If we are inventing a new solution, I’d like it also to solve OpenMP > declare simd legalization issue. If a small extension of existing scheme > > works for mathlib only, I’m happy to take that and discuss OpenMP >

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

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