search for: fwinter

...Backtrace: Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". e-m:e-i64:64-f80:128-n8:16:32:64-S128 Program received signal SIGSEGV, Segmentation fault. 0x00007ffff5f65832 in llvm::SmallVectorTemplateCommon<unsigned char, void>::end (this=0x148) at /home/fwinter/svn/llvm-3.9/include/llvm/ADT/SmallVector.h:117 117 iterator end() { return (iterator)this->EndX; } (gdb) bt #0 0x00007ffff5f65832 in llvm::SmallVectorTemplateCommon<unsigned char, void>::end (this=0x148) at /home/fwinter/svn/llvm-3.9/include/llvm/ADT/SmallVector.h:117 #1 llvm::Sm...

...ib/x86_64-linux-gnu/libthread_db.so.1". >> e-m:e-i64:64-f80:128-n8:16:32:64-S128 >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x00007ffff5f65832 in llvm::SmallVectorTemplateCommon<unsigned char, >> void>::end (this=0x148) at >> /home/fwinter/svn/llvm-3.9/include/llvm/ADT/SmallVector.h:117 >> 117 iterator end() { return (iterator)this->EndX; } >> (gdb) bt >> #0 0x00007ffff5f65832 in llvm::SmallVectorTemplateCommon<unsigned >> char, void>::end (this=0x148) at >> /home/fwinter/svn/llvm-3.9/in...

On 15 November 2013 20:05, Frank Winter <fwinter at jlab.org> wrote: > Good catch! That was the problem in my case too. I totally > overlooked the alignment requirement for AVX. I wonder if the validation mechanism shouldn't have caught it earlier... Do you guys run validate on the modules before JIT-ing? --renato --------------...

...? One of both solutions will be needed, I guess. Frank On 05/11/13 22:12, Andrew Trick wrote: > > On Oct 30, 2013, at 11:21 PM, Renato Golin <renato.golin at linaro.org > <mailto:renato.golin at linaro.org>> wrote: > >> On 30 October 2013 18:40, Frank Winter <fwinter at jlab.org >> <mailto:fwinter at jlab.org>> wrote: >> >> const std::uint64_t ir0 = (i+0)%4; // not working >> >> >> I thought this would be the case when I saw the original expression. >> Maybe we need to teach module arithmetic to SC...

Hmm.. I don't quite understand. How can a module validator catch this, when it's the pointers, i.e. the payload, you pass as function arguments that need to be aligned.. ?! Frank On 15/11/13 15:16, Renato Golin wrote: > On 15 November 2013 20:05, Frank Winter <fwinter at jlab.org > <mailto:fwinter at jlab.org>> wrote: > > Good catch! That was the problem in my case too. I totally > overlooked the alignment requirement for AVX. > > > I wonder if the validation mechanism shouldn't have caught it > earlier... Do you gu...

On 1 July 2015 at 21:22, Frank Winter <fwinter at jlab.org> wrote: > there were two follow-up emails. I only got one... weird... > The issue is solved. The SLP vectorizer has > a magic number built into the code which determines the max. vector length > to search for. That was set to 128 bits. Increasing it to 256 bits solved...

On 06/11/13 08:54, Arnold wrote: > > > Sent from my iPhone > > On Nov 5, 2013, at 7:39 PM, Frank Winter <fwinter at jlab.org > <mailto:fwinter at jlab.org>> wrote: > >> Good that you bring this up. I still have no solution to this >> vectorization problem. >> >> However, I can rewrite the code and insert a second loop which >> eliminates the 'urem' and &...

On 30 October 2013 18:40, Frank Winter <fwinter at jlab.org> wrote: > const std::uint64_t ir0 = (i+0)%4; // not working > I thought this would be the case when I saw the original expression. Maybe we need to teach module arithmetic to SCEV? --renato -------------- next part -------------- An HTML attachment was scrubbed... UR...

Sent from my iPhone > On Nov 5, 2013, at 7:39 PM, Frank Winter <fwinter at jlab.org> wrote: > > Good that you bring this up. I still have no solution to this vectorization problem. > > However, I can rewrite the code and insert a second loop which eliminates the 'urem' and 'div' instructions in the index calculations. In this case, the...

...Why can’t you just write a small loop like this: for (i=0; i<4; i++) C[i] = A[i] + B[i] ?? Either the unroller will unroll it and the SLP-vectorizer will vectorize the unrolled iterations, or the loop-vectorizer would catch it. Thanks, Nadav On Oct 31, 2013, at 8:01 AM, Frank Winter <fwinter at jlab.org> wrote: > A quite small but yet complete example function which all vectorization passes fail to optimize: > > #include <cstdint> > #include <iostream> > > void bar(std::uint64_t start, std::uint64_t end, float * __restrict__ c, float * __restrict__...

...ke this: for (i=0; i<4; i++) > C[i] = A[i] + B[i] ?? Either the unroller will unroll it and the > SLP-vectorizer will vectorize the unrolled iterations, or the > loop-vectorizer would catch it. > > Thanks, > Nadav > > On Oct 31, 2013, at 8:01 AM, Frank Winter <fwinter at jlab.org > <mailto:fwinter at jlab.org>> wrote: > >> A quite small but yet complete example function which all >> vectorization passes fail to optimize: >> >> #include <cstdint> >> #include <iostream> >> >> void bar(std::uint...

On 12 November 2013 15:14, Frank Winter <fwinter at jlab.org> wrote: > I am asking because the option 'force-vector-width' is too restrictive. > I would like to leave open the possibility to use vector width 2. I was about to say that, and you saved us both one cycle. ;) What you could do is to force an architecture that does...

On 12 November 2013 15:53, Frank Winter <fwinter at jlab.org> wrote: > .. forcing the vector size to 4 does not prevent using AVX. > Sure. That's more for tests than anything else. So, there are ways of disabling stuf in Clang, for instance "-mattr=-avx" or "-target-feature -avx", but I'm not sure how you&...

...loop_minimal.ll All optimization passes miss the opportunity. It seems the SCEV AA pass doesn't understand modulo arithmetic. How can the SCEV AA pass be extended to handle this type of arithmetic? Frank On 31/10/13 02:21, Renato Golin wrote: > On 30 October 2013 18:40, Frank Winter <fwinter at jlab.org > <mailto:fwinter at jlab.org>> wrote: > > const std::uint64_t ir0 = (i+0)%4; // not working > > > I thought this would be the case when I saw the original expression. > Maybe we need to teach module arithmetic to SCEV? > > --renato ---...

...t sure that would fix your issue though, because that would mean we return the wrong alignment not none. > > If the call below returns 0 then something has gone wrong in setting up the data layout in your compilation pipeline. > > >> On Aug 7, 2014, at 2:18 PM, Frank Winter <fwinter at jlab.org> wrote: >> >> It's not reproducible with 'opt'. I call the SLP pass from my application and only then the wrong IR gets generated. >> >> On the attached module I call via the function pass manager: >> >> 1) TargetLibraryInfo with the...

...vectorizer This produces the wrong IR. On the other hand running the attached module through 'opt -slp-vectorizer' results in no code changes. What could I be missing here? Frank On 08/07/2014 04:29 PM, Arnold Schwaighofer wrote: >> On Aug 7, 2014, at 12:42 PM, Frank Winter <fwinter at jlab.org> wrote: >> >> MCJIT when lowering to x86-64 generates a MOVAPS (Move Aligned Packed Single-Precision Floating-Point Values) on a non-aligned memory address: >> >> movaps 88(%rdx), %xmm0 >> >> where %rdx comes in as a function argument with o...

Frank, It sounds like the SLP vectorizer thinks that it is more profitable to use 128bit wide operations (because 256bit operations are double pumped on Sandybridge). Did you see a different result on Haswell? Thanks, Nadav > On Jul 1, 2015, at 11:06 AM, Frank Winter <fwinter at jlab.org> wrote: > > I realized that the function parameters had no alignment attributes on them. However, even adding an alignment suitable for aligned loads on YMM, i.e. 32 bytes, didn't convince the vectorizer to use [8 x float]. > > define void @main(i64 %lo, i64 %hi, fl...

...^2) algorithm. You can try to increase this threshold to 128 and see if it helps. I also agree with Renato and Chad that adding a flag to tell the SLP-vectorizer to put more effort (compile time) into the problem is a good idea. Thanks, Nadav > On Aug 8, 2014, at 8:27 AM, Frank Winter <fwinter at jlab.org> wrote: > > I changed the max. recursion depth to 36, and tried then 1000 (from the original value of 12) and it did not improve SLP's optimization capabilities on my input function. For example, the attached function is (by design) perfectly vectorizable into 4-packed sin...

...ctorize this loop! LV: Found trip count: 4 LV: The Widest type: 64 bits. LV: The Widest register is: 256 bits. LV: Using user VF 4. Looks like I have to disable AVX somehow. (Which is sad on its own.) Frank On 12/11/13 10:34, Renato Golin wrote: > On 12 November 2013 15:14, Frank Winter <fwinter at jlab.org > <mailto:fwinter at jlab.org>> wrote: > > I am asking because the option 'force-vector-width' is too > restrictive. > I would like to leave open the possibility to use vector width 2. > > > I was about to say that, and you saved us...

On 12/11/13 11:01, Renato Golin wrote: > On 12 November 2013 15:53, Frank Winter <fwinter at jlab.org > <mailto:fwinter at jlab.org>> wrote: > > .. forcing the vector size to 4 does not prevent using AVX. > > > Sure. That's more for tests than anything else. > > So, there are ways of disabling stuf in Clang, for instance > "-mattr=-avx&...