similar to: [cfe-dev] [RFC] Expose user provided vector function for auto-vectorization.

Displaying 20 results from an estimated 50000 matches similar to: "[cfe-dev] [RFC] Expose user provided vector function for auto-vectorization."

2019 May 30
5
[cfe-dev] [RFC] Expose user provided vector function for auto-vectorization.
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
2019 May 29
2
[cfe-dev] [RFC] Expose user provided vector function for auto-vectorization.
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. 
2019 May 28
6
[RFC] Expose user provided vector function for auto-vectorization.
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
2019 May 29
2
[cfe-dev] [RFC] Expose user provided vector function for auto-vectorization.
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
2019 May 31
2
[cfe-dev] [RFC] Expose user provided vector function for auto-vectorization.
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,
2019 May 31
2
[cfe-dev] [RFC] Expose user provided vector function for auto-vectorization.
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
2019 May 31
2
[cfe-dev] [RFC] Expose user provided vector function for auto-vectorization.
I think we should split this discussion: TOPIC 1 & 2 & 4: How do implement all use cases and OpenMP 5.X features, including compatibility with other compilers and cross module support. TOPIC 3b & 5: Interoperability with clang declare (system vs. user declares) TOPIC 3a & 3c: floating point issues? I inlined comments for
2019 May 31
2
[cfe-dev] [RFC] Expose user provided vector function for auto-vectorization.
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
2019 May 31
5
[cfe-dev] [RFC] Expose user provided vector function for auto-vectorization.
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
2019 May 31
2
[cfe-dev] [RFC] Expose user provided vector function for auto-vectorization.
>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).
2019 May 31
2
[cfe-dev] [RFC] Expose user provided vector function for auto-vectorization.
>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,
2019 Jun 01
2
[cfe-dev] [RFC] Expose user provided vector function for auto-vectorization.
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
2019 May 31
2
[cfe-dev] [RFC] Expose user provided vector function for auto-vectorization.
On 05/31, Saito, Hideki wrote: > > >This works for variants that are created from definitions in the module but what about #omp declare simd declarations? > > I'm sorry that I haven't digested this thread in its entirety, but let me just deal with this one point for now. > Suppose #pragma omp declare simd is applied to foo(). I'd expect the corresponding Function
2018 Nov 30
2
[RFC] Re-implementing -fveclib with OpenMP
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
2019 Jun 11
2
RFC: Interface user provided vector functions with the vectorizer.
Dear all, I have re-written the proposal for interfacing user provided vector functions, originally posted in both llvm-dev and cfe-dev mailing list: "[RFC] Expose user provided vector function for auto-vectorization." The proposal looks quite different from the original submission, therefore I took the liberty to start a new thread. The original thread generated some good
2019 Jun 17
3
RFC: Interface user provided vector functions with the vectorizer.
I agree with Simon. This looks good conceptually. I have minor implementation comments but that can wait till the code reviews. Sorry for the delay and thanks for working on this. Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Simon Moll <moll at cs.uni-saarland.de> Sent: Monday, June 17, 2019 10:02:58 AM To: Francesco Petrogalli; LLVM
2019 Jun 03
6
[cfe-dev] [RFC] Expose user provided vector function for auto-vectorization.
Hi All, The original intend of this thread is to "Expose user provided vector function for auto-vectorization.” I originally proposed to use OpenMP `declare variant` for the sake of using something that is defined by a standard. The RFC itself is not about fully implementing the `declare variant` directive. In fact, given the amount of complication it is bringing, I would like to move the
2019 Jun 21
2
RFC: Interface user provided vector functions with the vectorizer.
>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
2019 Jun 24
2
RFC: Interface user provided vector functions with the vectorizer.
I have an RFC for first-class complex types in LLVM IR pending for some internal review. I hope to post it soon. That should help address this problem. Then the vector function signature generation could stay in LLVM, if I'm understanding the issue correctly. -David Francesco Petrogalli via llvm-dev <llvm-dev at lists.llvm.org> writes: > Hi all - I am
2019 Jun 24
4
RFC: Interface user provided vector functions with the vectorizer.
@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