search for: vecclon

>VectorClone does more than just mapping a scalar version to a vector one. It builds also the vector version definition by auto-vectorizing the body of the scalar function. To be more precise: VecClone strictly deals with the callee side of the code. Caller side mapping happens in vectorizer (LoopVectorize for the most part, but I don't see why SLPVectorize can't, for example). Starting from the scalar code, for each "_ZGV..." name it finds in the function attribute, VecClone w...

...f OpenMP (declare) simd. Else, vectorization report would tell you whether it was vectorized or not. >How does OpenCL/SYCL play in this now? Not right now, when we are working to get OpenMP stuff going --- except that I don't think we need to change the design (e.g., on function attribute, VecClone direction, etc.) in the future for those or similar languages. -----Original Message----- From: Doerfert, Johannes [mailto:jdoerfert at anl.gov] Sent: Friday, May 31, 2019 4:16 PM To: Saito, Hideki <hideki.saito at intel.com> Cc: Francesco Petrogalli <Francesco.Petrogalli at arm.com>;...

.... I don't think that precludes the approach you've taken though. > >How does OpenCL/SYCL play in this now? > > Not right now, when we are working to get OpenMP stuff going --- > except that I don't think we need to change the design (e.g., on > function attribute, VecClone direction, etc.) in the future for those > or similar languages. OK. Whatever is considered here, if you think there is a problem to reuse that for OpenCL/SYCL, let us know. > -----Original Message----- > From: Doerfert, Johannes [mailto:jdoerfert at anl.gov] > Sent: Friday, May 31...

...ilable that are specializations of foo. When we then vectorize foo (or otherwise specialize at some point in the future), you would scan the module and pick the best match based on the context of the call. Now I don't know if I understood your proposal by now but let me ask a question anyway: VecClone.cpp:276-278 mentions that the vectorizer is supposed to look at the vector-variants functions. This works for variants that are created from definitions in the module but what about #omp declare simd declarations? On 05/31, Francesco Petrogalli wrote: > > On May 31, 2019, at 11:47 AM, Doer...

...clare variant` is a modification of the one needed for `declare simd`, which has already been agreed in a previous RFC proposed by Intel [1], and for which Intel has already provided an implementation [2]. The changes proposed in this RFC are fully compatible with the work that is being don for the VecClone pass in [2]. > > [1] http://lists.llvm.org/pipermail/cfe-dev/2016-March/047732.html > [2] VecCLone pass: https://reviews.llvm.org/D22792 > > The good news is that as far as AArch64 and x86 are concerned, the only thing that will differ in the mangled name is the “<isa>” toke...

...modification of the one needed for `declare simd`, which has already > been agreed in a previous RFC proposed by Intel [1], and for which > Intel has already provided an implementation [2]. The changes proposed > in this RFC are fully compatible with the work that is being don for > the VecClone pass in [2]. > > [1] http://lists.llvm.org/pipermail/cfe-dev/2016-March/047732.html > [2] VecCLone pass: https://reviews.llvm.org/D22792 Having an agreed upon mangling for the older feature is not necessarily important here. We will need more functionality for variants and keeping the o...

...clare variant` is a modification of the one needed for `declare simd`, which has already been agreed in a previous RFC proposed by Intel [1], and for which Intel has already provided an implementation [2]. The changes proposed in this RFC are fully compatible with the work that is being don for the VecClone pass in [2]. >>> >>> [1] http://lists.llvm.org/pipermail/cfe-dev/2016-March/047732.html >>> [2] VecCLone pass: https://reviews.llvm.org/D22792 >>> >>> The good news is that as far as AArch64 and x86 are concerned, the only thing that will differ in th...

...clare variant` is a modification of the one needed for `declare simd`, which has already been agreed in a previous RFC proposed by Intel [1], and for which Intel has already provided an implementation [2]. The changes proposed in this RFC are fully compatible with the work that is being don for the VecClone pass in [2]. >>>>> >>>>> [1] http://lists.llvm.org/pipermail/cfe-dev/2016-March/047732.html >>>>> [2] VecCLone pass: https://reviews.llvm.org/D22792 >>>>> >>>>> The good news is that as far as AArch64 and x86 are concerne...

...ializations of foo. When we then vectorize foo (or otherwise specialize at some point in the future), you would scan the module and pick the best match based on the context of the call. > > Now I don't know if I understood your proposal by now but let me ask a question anyway: > > VecClone.cpp:276-278 mentions that the vectorizer is supposed to look at the vector-variants functions. This works for variants that are created from definitions in the module but what about #omp declare simd declarations? > > > On 05/31, Francesco Petrogalli wrote: > > > On May 31, 201...

...you've taken though. >> >>>> How does OpenCL/SYCL play in this now? >>> >>> Not right now, when we are working to get OpenMP stuff going --- >>> except that I don't think we need to change the design (e.g., on >>> function attribute, VecClone direction, etc.) in the future for those >>> or similar languages. >> >> OK. Whatever is considered here, if you think there is a problem to reuse that for OpenCL/SYCL, let us know. >> >> >>> -----Original Message----- >>> From: Doerfert, Joha...

...clare variant` is a modification of the one needed for `declare simd`, which has already been agreed in a previous RFC proposed by Intel [1], and for which Intel has already provided an implementation [2]. The changes proposed in this RFC are fully compatible with the work that is being don for the VecClone pass in [2]. >>>>>>> >>>>>>> [1] http://lists.llvm.org/pipermail/cfe-dev/2016-March/047732.html >>>>>>> [2] VecCLone pass: https://reviews.llvm.org/D22792 >>>>>>> >>>>>>> The good news is tha...

On 5/30/19 9:05 AM, Doerfert, Johannes wrote: > On 05/29, Finkel, Hal J. via cfe-dev wrote: >> On 5/29/19 1:52 PM, Philip Reames wrote: >>> On 5/28/19 7:55 PM, Finkel, Hal J. wrote: >>>> On 5/28/19 3:31 PM, Philip Reames via cfe-dev wrote: >>>>> I generally like the idea of having support in IR for vectorization of >>>>> custom

Hi Francesco, On 06/03, Francesco Petrogalli wrote: > > On Jun 3, 2019, at 1:43 PM, Andrea Bocci <andrea.bocci at cern.ch> wrote: > > as a candidate future user of the proposed extension, I think I like the simplified proposal better than the original RFC. > > > > The only part of the syntax that I would find not very much user-friendly is having to mangle the

>Thank you everybody for their input, and for your patience. This is proving harder than expected! :) Thank you for doing the hard part of the work. Hideki -----Original Message----- From: Francesco Petrogalli [mailto:Francesco.Petrogalli at arm.com] Sent: Monday, June 24, 2019 11:26 AM To: Saito, Hideki <hideki.saito at intel.com> Cc: Doerfert, Johannes <jdoerfert at anl.gov>;

...ar Operands   While it is important to keep refactoring the above mentioned items such that entire LV becomes fully VPlan based (which completes the transition into VPlan infrastructure), we are aware that there is also a need to make progress in outer loop vectorization. Function vectorization via VecClone pass (https://reviews.llvm.org/D22792) also depends on the progress of outer loop vectorization.   ============== Proposed Plan: ============== Instead of waiting for most of the above mentioned refactoring to finish before working on outer loop vectorization, we believe it serves the best interes...

...ariant`. 2. The scope of the proposal is not enabling the vectorizer to do new kind of vectorizations (e.g. RV-like vectorization described by Simon). 3. The proposal aims to be extendible wrt 1. and 2. 4. The IR attribute introduced in this proposal is equivalent to the one needed for the VecClone pass under development in https://reviews.llvm.org/D22792 # CLANG COMPONENTS A C function attribute, `clang_declare_simd_variant`, to attach to the scalar version. The attribute provides enough information to the compiler about the vector shape of the user defined function. The vector shapes...

...> > While it is important to keep refactoring the above mentioned items such that entire LV becomes fully VPlan based (which completes the transition into VPlan infrastructure), we are aware that there is also a need to make progress in outer loop vectorization. Function vectorization via VecClone pass (https://reviews.llvm.org/D22792) also depends on the progress of outer loop vectorization. > > ============== > Proposed Plan: > ============== > Instead of waiting for most of the above mentioned refactoring to finish before working on outer loop vectorization, we believe...

...>> While it is important to keep refactoring the above mentioned items such that entire LV becomes fully VPlan based (which completes the transition into VPlan infrastructure), we are aware that there is also a need to make progress in outer loop vectorization. Function vectorization via VecClone pass (https://reviews.llvm.org/D22792) also depends on the progress of outer loop vectorization. >> >> ============== >> Proposed Plan: >> ============== >> Instead of waiting for most of the above mentioned refactoring to finish before working on outer loop vecto...

...proposal is not enabling the vectorizer to do new > kind of vectorizations (e.g. RV-like vectorization described by > Simon). > 3. The proposal aims to be extendible wrt 1. and 2. > 4. The IR attribute introduced in this proposal is equivalent to the > one needed for the VecClone pass under development in > https://reviews.llvm.org/D22792 > > # CLANG COMPONENTS > > A C function attribute, `clang_declare_simd_variant`, to attach to the > scalar version. The attribute provides enough information to the > compiler about the vector shape of the user de...

...o new >> > kind of vectorizations (e.g. RV-like vectorization described by >> > Simon). >> > 3. The proposal aims to be extendible wrt 1. and 2. >> > 4. The IR attribute introduced in this proposal is equivalent to the >> > one needed for the VecClone pass under development in >> > https://reviews.llvm.org/D22792> > >> > # CLANG COMPONENTS >> > >> > A C function attribute, `clang_declare_simd_variant`, to attach to the >> > scalar version. The attribute provides enough information to the &g...