similar to: [LLVMdev] BoF: Vectorization in LLVM

----- Original Message ----- > From: "Nadav Rotem" <nrotem at apple.com> > To: "David Tweed" <david.tweed at gmail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Tuesday, November 6, 2012 11:08:23 AM > Subject: Re: [LLVMdev] Regarding BOF: Vectorization in LLVM > > Hi David! > > On Nov 6, 2012, at 3:23 AM, David Tweed <david.tweed at

Hi David! On Nov 6, 2012, at 3:23 AM, David Tweed <david.tweed at gmail.com> wrote: > Hi Nadav, > > Unfortunately I'm not attending the dev meeting, but the BoF looks interesting. One thing that I'd like to throw into the mix is that, while dealing with autovectorisation of LLVM compiled down from C-like languages (or maybe Fortran-like languages) is clearly a very big

On Tue, Nov 6, 2012 at 6:11 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Nadav Rotem" <nrotem at apple.com> >> To: "David Tweed" <david.tweed at gmail.com> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Tuesday, November 6, 2012 11:08:23 AM >> Subject: Re: [LLVMdev] Regarding BOF: Vectorization in

Hi Nadav, Unfortunately I'm not attending the dev meeting, but the BoF looks interesting. One thing that I'd like to throw into the mix is that, while dealing with autovectorisation of LLVM compiled down from C-like languages (or maybe Fortran-like languages) is clearly a very big area for fruitful work both algorithmically and in terms of practical relevance, it'd also be interesting

On 10/08/2012 06:02 AM, Nadav Rotem wrote: > Hi Javed, > > Developing a good loop vectorizer takes several years. The work on the GCC vectorizer began in 2004, and they spent several years improving and optimizing their vectorizer. They started by vectorizing simple loops, and added features that they needed in order to vectorize additional loops that were important for them. They

On Nov 6, 2012, at 10:45 AM, David Tweed <david.tweed at gmail.com> wrote: > I'll certainly try to do this, although I suspect it's going to be > more of a matter of mutual interaction from both ends: > > * DSL developers: I could tell you these things: ...., can you > profitably use them? > * Autovectorizer developers: I can make use of these things: ...., are

So IMO, if we modify the VF calculation for targets/subtargets using TTI where higher VF is supported The vectorizer’s scope will become wider. Did/do you foresee any issue with this? Thanks, Shahid From: Nadav Rotem [mailto:nrotem at apple.com] Sent: Saturday, December 13, 2014 2:47 AM To: Shahid, Asghar-ahmad Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Vectorization factor limitation in

Renato, can you post the c code for the function and the assembly that gcc produces? Your initial example could be well handled by vectorization of strided loops (and the mentioning of VLD3(.8?)/VST3(.8?) lead me to assume that this is what happened). But the LLVM-IR you sent has a store of 0 in there ;) and strides by 4. Thanks, Arnold Vectorization of strided loops: I am using float as the

This is almost ideal for SLP vectorization, except for two problems: 1. We have 4 stores to consecutive locations, but the last element is the constant zero, and not an additional SUB. At the moment we don’t have support for idempotence operations, but this is something that we should add. 2. The values that we are subtracting come from 3 loads. We usually load 4 elements from memory, or

On Oct 7, 2012, at 11:53 PM, Tobias Grosser <tobias at grosser.es> wrote: > As the design of the vectorizer is a very hot topic, I was wondering if there will be a BoF session on the LLVM conference? Nadav, you have not proposed one by accident? I proposed a BoF, and (if accepted) we can start discussing the design of the llvm loop vectorizer and the infrastructure that we need for

Nadav and Arnold, What is the current status of vectorization pragmas? Do you think that's something I might be able to take on if you two are busy with other things? Stephen On Thu, Nov 14, 2013 at 11:10 AM, Nadav Rotem <nrotem at apple.com> wrote: > Its a good point. We will need to document the semantics of the > vectorization pragma well. > > On Nov 14, 2013, at

Its a good point. We will need to document the semantics of the vectorization pragma well. On Nov 14, 2013, at 10:58 AM, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi Nadav, > > On 14/11/13 17:38, Nadav Rotem wrote: >> Sure. Vectorization of stores is done by loading the current value from memory, blending the new value and saving it back to memory. > > Just a

Hi Nadav, On Thu, Jan 3, 2013 at 1:53 PM, Nadav Rotem <nrotem at apple.com> wrote: > Hi Akira! > > > > > Does the current loop vectorizer inquire about the SIMD capabilities of > the target architecture when it decides whether it is profitable to > vectorize a loop? > > Yes, it uses a cost model to determine the profitability of vectorization. > At the

On 14 October 2013 18:15, Nadav Rotem <nrotem at apple.com> wrote: > 1. We have 4 stores to consecutive locations, but the last element is the > constant zero, and not an additional SUB. At the moment we don’t have > support for idempotence operations, but this is something that we should > add. > The fourth write is not necessary for GCC to vectorize it (nor was in the

Hi Renato, Thanks for working on this. As you said, we don't support pointer reductions. Handling pointer reductions should be straightforward. You can copy the logic for handling RK_IntegerAdd and create a new enum entry for RK_PointerAdd. You will need to detect the relevant patterns (GEP probably) and implement the cost model and vectorization parts. You will need to generate

Hi Nadav, No noticeable difference between "-Os" and "-Os -fvectorize" in code size or compilation times in my tests, and only minimal performance improvements (small enough to be ignored). cheers, --renato On 14 June 2013 09:29, Renato Golin <renato.golin at linaro.org> wrote: > On 14 June 2013 05:37, Nadav Rotem <nrotem at apple.com> wrote: > >>

Nadav, I believe aligned accesses to unaligned pointers is precisely the issue. Consider the function `add_u8S` before[1] and after[2] the loop vectorizer pass. There is no alignment assumption associated with %kernel_data prior to vectorization. I can't tell if it's the loop vectorizer or the codegen at fault, but the alignment assumption seems to sneak in somewhere. v/r, Josh [1]

Has anyone worked with or used the LLVM backend or compiler for Haskell ?? David On Monday, October 21, 2013 5:26 PM, "llvmdev-request at cs.uiuc.edu" <llvmdev-request at cs.uiuc.edu> wrote: Send LLVMdev mailing list submissions to     llvmdev at cs.uiuc.edu To subscribe or unsubscribe via the World Wide Web, visit     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev or,

Hi Javed, Developing a good loop vectorizer takes several years. The work on the GCC vectorizer began in 2004, and they spent several years improving and optimizing their vectorizer. They started by vectorizing simple loops, and added features that they needed in order to vectorize additional loops that were important for them. They started with a single-block loops, and later they added

On 14 June 2013 05:37, Nadav Rotem <nrotem at apple.com> wrote: > Last week I wrote llvm-dev and presented data that shows how enabling the > vectorizer on -Os can improve the performance of many workloads and that it > has negligible effects on code size. I also added a command line switch to > make it easier for people to benchmark the vectorizer using -Os directly > from