similar to: [LLVMdev] make check rebuilds the project?

Because almost no other piece of software out there doesn't have 'check' depend on rebuilding the target it's testing and it's bitten people whereas other than the lameness of our build system needing to recurse all the directories to figure out that all has already been rebuilt there's no penalty to requiring the dependency. :) -eric On Wed, Apr 17, 2013 at 9:35 AM, Bob

Eric changed it in svn 179116. He didn't provide any explanation in the commit message. Eric, why did you do that? On Apr 17, 2013, at 8:30 AM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > It appears the behavior of "make check" has changed recently (configure style build). I believe it used to just run the tests. Now, it seems to recompile the project just

On Sep 27, 2013, at 12:47 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > so you could infer that n must be smaller than 8 (because you know the range of the other dimension). The question is how often does such an example occur, where this is possible, to make such an effort justifiable? smaller equal, of course ;)

Hi Hal, On Feb 4, 2013, at 2:09 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Renato Golin" <renato.golin at linaro.org> >> To: "Arnold Schwaighofer" <aschwaighofer at apple.com> >> Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Nadav Rotem" <nrotem at apple.com>, "Hal

Hey Arnold, I have run into this situation many times while benchmarking. I think it is best if this is addressed using a simple heuristic. For that, we need to identify the loop cost and decide if it makes sense to completely unroll the loop, or partially unroll. I am unsure of the optimal way to implement this though. I want to run it by the list to get any ideas floating around :) Thanks

Yes, I was just about to send out: DL->getABITypeAlignment(ScalarDataTy); The question is: “… ABI alignment for the target …" is that getPrefTypeAlignment or getABITypeAlignment I would have thought the latter. On Nov 15, 2013, at 4:12 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Arnold Schwaighofer"

In order to vectorize code like this LLVM needs to prove that “A[i*7]” does not wrap in the address space. It fails to do so and so LLVM doesn’t vectorize this loop even if we try to force it. The following loop will be vectorized if we force it: int foo(int * A, int * B, int n, int k) { for (int i = 0; i < 1024; ++i) A[i] += B[i*k]; } So will this loop: int foo(int * restrict A, int

> On Aug 7, 2014, at 2:57 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > > Your .ll file does not have a data layout. Opt will not initialize the DataLayoutPass. The SLP vectorizer will not vectorize because there is no DataLayoutPass. > > debug-cmake/bin/opt -default-data-layout="e-m:e-i64:64-f80:128-n8:16:32:64-S128" -basicaa -slp-vectorizer -S

On Tue, Jan 21, 2014 at 2:44 PM, Arnold Schwaighofer < aschwaighofer at apple.com> wrote: > The LoopVectorizer depends on LCSSA and LoopSimplify. Both are loop > passes. We will have to make them also available as utility functions. Yuck. We still need to fix these at least, but that's much better than teaching *all* the loop passes to preserve BPI and BFI. -------------- next

On 21 October 2013 17:29, Arnold Schwaighofer <aschwaighofer at apple.com>wrote: > I don’t think that recognizing this as a reduction is going to get you > far. A reduction is beneficial if the value reduced is only truly needed > outside of a loop. > This is not the case here (we are storing/loading from the pointer). > Hi Arnold, Nadav, Let me resurrect this discussion a

On 7 June 2013 14:49, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > It is not the vectorizer that is the issue, it is the ARM backend that > currently translates vectorized floating point IR to NEON instructions (it > should scalarize it if desired to do so - i.e. if people care about > denormals). > Hi Arnold, Can't the vectorizer not generate the v4f32

On Mar 12, 2014, at 4:05 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Wed, Mar 12, 2014 at 3:50 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > In order to vectorize code like this LLVM needs to prove that “A[i*7]” does not wrap in the address space. It fails to do so > > But, why? > > I'm moderately sure that neither C nor C++

In r200270 I added support to unroll conditional stores in the loop vectorizer. It is currently off pending further benchmarking and can be enabled with "-mllvm -vectorize-num-stores-pred=1”. Furthermore, I added a heuristic to unroll until load/store ports are saturated “-mllvm enable-loadstore-runtime-unroll” instead of the pure size based heuristic. Those two together with a patch that

On May 23, 2013, at 9:15 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 23 May 2013 14:52, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > I would like us to grow a few annotations, among others, one to force vectorization irrespective whether the loop vectorizer thinks it is beneficial or not - however, this is future music. > > Isn't that part

On 7 June 2013 15:41, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > We don’t want to encode backend knowledge into the vectorizer (i.e. don’t > vectorize type X because the backend does not support it). > We already do, via the cost table. This case is no different. It might not be the best choice, but it is how the cost table is being built over the last months. The

Ok any quick workaround to limit vectorization to 16-byte aligned 128-bit data then? All the memory copying done by ExpandUnalignedStore/ExpandUnalignedLoad is just too expensive. On Sat, Jul 20, 2013 at 12:52 PM, Arnold Schwaighofer < aschwaighofer at apple.com> wrote: > > On Jul 19, 2013, at 3:14 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > > > >

Hi Arnold, To sum up my intentions, I want to understand how the reduction/induction variable detection works in LLVM, so that I can know better how to detect different patterns in memory, not just the stride vectorization. For instance, even if the relationship between each loop would be complicated, I know that in each loop, all three reads are sequential. So, at least, I could use a

On 08/20, Arnold Schwaighofer wrote: > > > On Aug 20, 2014, at 8:08 AM, Robison, Arch <arch.robison at intel.com> wrote: > > > >> I recommend that you send patches for an implementation > >> (including the Loop::GetAnnotatedVectorSafelen function > >> and associated updates to the vectorizer) for review. > > > > I expect to send the

Something like: index 6db7f68..68564cb 100644 --- a/lib/Transforms/Vectorize/LoopVectorize.cpp +++ b/lib/Transforms/Vectorize/LoopVectorize.cpp @@ -1208,6 +1208,8 @@ void InnerLoopVectorizer::vectorizeMemoryInstruction(Instr Type *DataTy = VectorType::get(ScalarDataTy, VF); Value *Ptr = LI ? LI->getPointerOperand() : SI->getPointerOperand(); unsigned Alignment = LI ?

----- Original Message ----- > From: "Arnold Schwaighofer" <aschwaighofer at apple.com> > To: "Joshua Klontz" <josh.klontz at gmail.com> > Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu> > Sent: Friday, November 15, 2013 4:05:53 PM > Subject: Re: [LLVMdev] Limit loop vectorizer to SSE > > > Something like: > > index