similar to: [RFC] Enable "#pragma omp declare simd" in the LoopVectorizer

Hi Xinmin, I have updated the clang patch using the standard name mangling you suggested - I was not fully aware of the C++ mangling convention “_ZVG”. I am using “D” for 64-bit NEON and “Q” for 128-bit NEON, which makes NEON vector symbols look as follows: _ZVGQN2v__Z1fd _ZVGDN2v__Z1ff _ZVGQN4v__Z1ff Here “Q” means -> NEON 128-bit, “D” means -> NEON 64-bit Please notice that although

Hi Francesco, a bit more information. GCC veclib is implemented based on GCC VectorABI for declare simd as well. For name mangling, we have to follow certain rules of C/C++ (e.g. prefix needs to _ZVG ....). David Majnemer who is the owner and stakeholder for approval for Clang and LLVM. Also, we need to pay attention to GCC compatibility. I would suggest you look into how GCC VectorABI can

On 8 December 2016 at 18:11, Tian, Xinmin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > For name mangling, we have to follow certain rules of C/C++ (e.g. prefix needs to _ZVG ....). David Majnemer who is the owner and stakeholder for approval for Clang and LLVM. Also, we need to pay attention to GCC compatibility. I would suggest you look into how GCC VectorABI can be extended

Hi Michael. Thank for your feedback and questions/comments. See below. >>>>>I think it should be possible to vectorize such loop even without openmp clauses. We just need to gather a vector value from several scalar calls, and vectorizer already knows how to do that, we just need not to bail out early. Dealing with calls is tricky, but in this case we have the pragma, so we can

Proposal for function vectorization and loop vectorization with function calls ============================================================================== Intel Corporation (3/2/2016) This is a proposal for an initial work towards Clang and LLVM implementation of vectorizing a function annotated with OpenMP 4.5's "#pragma omp declare simd" (named SIMD-enabled function) and its

Dear all, This RFC is a proposal to provide auto-vectorization functionality for user provided vector functions. The proposal is a modification of an RFC that I have sent out a couple of months ago, with the title `[RFC] Re-implementing -fveclib with OpenMP` (see http://lists.llvm.org/pipermail/llvm-dev/2018-December/128426.html). The previous RFC is to be considered abandoned. The original RFC

Hi all, I am submitting the following RFC [1] to re-implement -fveclib via OpenMP constructs. The RFC was discussed during a round table at the last LLVM developer meeting, and presented during the BoF [2]. The proposal is published on Phabricator, for the purpose of keeping track of the comments, and it now ready for a review from a wider audience after being polished by Hal Finkel and Hideki

Yes, this is very similar, but only expressed in terms of clang attributes, which may have different spellings for clang, GCC, c++11 etc. I don't think GCC will implement this as pragma. They added simd attribute instead of pragma. Best regards, Alexey Bataev > 31 мая 2019 г., в 14:43, Francesco Petrogalli <Francesco.Petrogalli at arm.com> написал(а): > > > >> On

You can define clang specific attribute and later add GCC alias for it. Best regards, Alexey Bataev > 31 мая 2019 г., в 13:46, Francesco Petrogalli <Francesco.Petrogalli at arm.com> написал(а): > > > >> On May 31, 2019, at 12:38 PM, Alexey Bataev <a.bataev at hotmail.com> wrote: >> >> Francesco, there won't be any duplication. Most of the

@Xinmin, Saito: If Clang/the frontend generates the version there is no problem, or is there? The frontend knows about the original source type and it's ABI specific lowering already. @Francesco, we should even consider putting the generating capabilities outside of the OpenMP code generation (in the future). That could allow easier reuse by other frontends. Get Outlook for

Francesco, there won't be any duplication. Most of the declarative OpenMP directives are represented as attributes internally, so, I think, it will be natural to use an attribute here rather than pragma. Best regards, Alexey Bataev > 31 мая 2019 г., в 13:32, Francesco Petrogalli <Francesco.Petrogalli at arm.com> написал(а): > > > >> On May 31, 2019, at 12:00 PM,

Hi Francesco, did you think about adding the attribute instead of the pragma? It is a common way to express such constructs as function attributes in clang/GCC rather than as pragma. Best regards, Alexey Bataev > 31 мая 2019 г., в 12:18, Francesco Petrogalli via cfe-dev <cfe-dev at lists.llvm.org> написал(а): > > Hi All, > > Thank you for the feedback so far. > > I

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

>In all cases, the IR type of the parameters in `foo` is i64, therefore is not possible to distinguish what C type generated the signature of `foo`. Ouch. >I don’t know if this is going to be a problem for other architectures I haven't checked what IA-32/Intel64 should do for type 2, but I fully agree that this needs to be done properly according to the ABI. >Therefore, I would

Page 22 of OpenMP 5.0 specification (Lines 13/14): When any thread encounters a simd construct, the iterations of the loop associated with the construct may be executed concurrently using the SIMD lanes that are available to the thread This is the Execution Model. The word here is "may" i.e., not "must". Declare simd is not explicitly mentioned here, but requiring

I think I did misunderstand what you want to do with attributes. This is my bad. Let me try to explain: It seems you want the "vector-variants" attributes (which I could not find with this name in trunk, correct?) to "remember" what vector versions can be created (wrt. validity), assuming a definition is available? Correct? What I was concerned with is the example I sketched

>Is this also the case if the user did require lock-step semantic for the code to be correct? Certainly not, but that part is actually beyond OpenMP specification. I suggest looking up ICC's "#pragma simd assert" description and see if the assert feature is something you may be interested in seeing as an extended part of LLVM implementation of OpenMP (declare) simd. Else,

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

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 functions.  I have several use cases which would benefit from this. > > I'd suggest a couple of reframings to the IR representation though. > > First, this should probably be specified as metadata/attribute on a > function declaration. 

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 functions.  I have several use cases which would benefit from this. >>> >>> I'd suggest a couple of reframings to the IR