search for: d22792

...ility of a particular transform the buggier it will tend to be. The work here to allow vectorization of an every-wider set of inputs will really help to expose, and thus help us eliminate, bugs. As such, one of the largest benefits of adding the function-vectorization work (https://reviews.llvm.org/D22792), and outer-loop vectorization capabilities, will be making it easier to throw essentially-arbitrary inputs at the vectorizer (and have it do something), and thus, hit it more effectively with automated testing. Maybe we can do a better job, even with the current capabilities, of automatically gen...

...ectorization. When such a function has a loop inside, the loop vectorization needed in that scenario is "outer loop vectorization". http://lists.llvm.org/pipermail/cfe-dev/2016-March/047732.html (X. Tian, RFC for vectorizing a call --- caller side and callee side) https://reviews.llvm.org/D22792 (M. Masten, Converting Function Vectorization to Loop Vectorization) https://reviews.llvm.org/D40575 (M. Masten, Caller side support for invoking vector function from vector loop) Related work of related work. Math lib vectorization using SVML. http://lists.llvm.org/pipermail/llvm-dev/2016-March/0...

...t SIMD architectures", Dorit Nuzman and Ayal Zaks, PACT 2008. [2] "Proposal for function vectorization and loop vectorization with function calls", Xinmin Tian, [cfe-dev] March 2, 2016 (http://lists.llvm.org/pipermail/cfe-dev/2016-March/047732.html. See also https://reviews.llvm.org/D22792). [3] "Throttling Automatic Vectorization: When Less is More", Vasileios Porpodas and Tim Jones, PACT 2015 and LLVM Developers' Meeting 2015. [4] "Intel OpenCL SDK Vectorizer", Nadav Rotem, LLVM Developers' Meeting 2011. [5] "Automatic SIMD Vectorization of SSA-b...

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

...eep 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 interest of the comm...

...eep 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 interest of the community if we start making c...

...rizer 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 handled by the attribute are those handled by the OpenMP stand...

...ectorizations (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 handled by the attribute are...

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

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

...tted, and both are adhering the name mangling proposed by Xinmin's RFC. A) committed - the FE portion by Alexey [https://reviews.llvm.org/rL264853], it generates mangled names in the manner described by Xinmin's RFC, See below B) Submitted - the callee side by Matt [https://reviews.llvm.org/D22792], it uses these mangled names. and C) caller which is covered by this patch. In order to mitigate the needed effort and possible issues when implementing, I believe it is best to follow the name mangling proposed in Xinmin's RFC. What do you think? GCC Example ---------------- Compiler versio...

...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>” token. As far as I can tell, the mangling scheme of the rest of the vector name is the same, therefore a lot of infrastructure in terms of mangling and...

...re >adhering the name mangling proposed by Xinmin's RFC. A) committed - the >FE portion by Alexey [https://reviews.llvm.org/rL264853], it generates >mangled names in the manner described by Xinmin's RFC, See below B) >Submitted - the callee side by Matt [https://reviews.llvm.org/D22792], it >uses these mangled names. and C) caller which is covered by this patch. > >In order to mitigate the needed effort and possible issues when >implementing, I believe it is best to follow the name mangling proposed >in Xinmin's RFC. What do you think? > >GCC Example >...

...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>” token. As far as I can tell, the mangling scheme of the rest of the vector name is the same, therefore a lot of infrastructure in terms...

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

...ion [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>” token. As far as I can tell, the mangling scheme of the rest of the vector name is the same, therefore a lot of infrastr...

...posed 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>” token. As far as I can tell, the mangling scheme of the rest of the vector name is the same, therefore a...

...el 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 old scheme around with some metadata is not an extensible long-term solution. So, I would not try to fit variants into the existing simd-scheme but i...

Dear all, I have just created a couple of differential reviews to enable the vectorisation of loops that have function calls to routines marked with “#pragma omp declare simd”. They can be (re)viewed here: * https://reviews.llvm.org/D27249 * https://reviews.llvm.org/D27250 The current implementation allows the loop vectorizer to generate vector code for source file as: #pragma omp declare

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