search for: aschwaighof

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

...ntify 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 Sriram -----Original Message----- From: Arnold Schwaighofer [mailto:aschwaighofer at apple.com] Sent: Friday, September 27, 2013 1:54 PM To: Murali, Sriram Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Trip count and Loop Vectorizer On Sep 27, 2013, at 12:47 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > so you could infer that n must be smalle...

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 Finkel" <hfinkel at anl.gov> >> Sent: Monday, February 4, 2013 1:38:03 PM >> Subject: Re: Vectorizer using Instruction, not opco...

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

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++ allow wrapping around the end of the address space. If they do,...

...n 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" <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 >> >> >> S...

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

...” instead of the pure size based heuristic. Those two together with a patch that slightly changes the register heuristic and libquantum’s three hot loops will unroll and goodness will ensue (at least for libquantum). commit 6b908b8b1084c97238cc642a3404a4285c21286f Author: Arnold Schwaighofer <aschwaighofer at apple.com> Date: Mon Jan 27 13:21:55 2014 -0800 Subtract one for loop induction variable. It is unlikely to be unrolled. diff --git a/lib/Transforms/Vectorize/LoopVectorize.cpp b/lib/Transforms/Vectorize/LoopVectorize.cpp index 7867495..978c5a1 100644 --- a/lib/Transforms/Vectorize/...

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

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: > > > > > What is the proper solution to disable auto-vectorization for unaligned > data? > > > > I have an out of tree target and I added this: &gt...

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

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 of the ivdep implementation? I thought there was...

----- 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 Finkel" <hfinkel at anl.gov> > Sent: Monday, February 4, 2013 1:38:03 PM > Subject: Re: Vectorizer using Instruction, not opcodes > &g...

I mistakenly not cc’ed the list. On Oct 23, 2013, at 8:28 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 23 October 2013 14:13, Arnold <aschwaighofer at apple.com> wrote: >> What I am proposing for interleaved data vectorization would not transform the loop before vectorization (because there is not much you can do in the general case). There would not be a need for any retries. > > I know, I digressed. > > >> We...

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 like a "make" would and then run the tests. Is it just me or are others seeing this too? Is this a intended behavior change? Best, Arnold

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 like a "make" would and then run the tests. Is it just me or are others see...

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 of the ivdep implementation? I thought the...

On 7 June 2013 18:08, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > What I am suggesting is that (if you care about denormals): > > * the arm backend has to be fixed to scalarize floating point vector > operations (behind a flag) > * the arm target transform model has to correctly reflect that > Yup. What I had in min...

If I got you right, this is the classic case for loop peeling. I thought LLVM's vectorizer had something like that already in. On 21 July 2013 18:16, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > I will have to work on this soon as ARM also has pretty inefficient > unaligned vector loads. > NEON does support unaligned access via VLD*/VST*, what loads are you referring to? cheers, --renato -------------- next part -------------- An HTML attachment was...

----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Arnold Schwaighofer" <aschwaighofer at apple.com>, "Arch Robison" <arch.robison at intel.com>, "LLVM Dev" > <llvmdev at cs.uiuc.edu> > Sent: Wednesday, August 20, 2014 2:16:56 PM > Subject: Re: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" > > On 20 August 201...