Displaying 20 results from an estimated 1000 matches similar to: ": Does OpenMP hints bypass the vectorisation legality check in llvm"
2018 Jan 19
1
Does OpenMP hints bypass the vectorisation legality check in llvm
Tom,
Let me go a little deeper. Xinmin's answer is correct but a bit over-simplified.
There are parts of "legality" and "cost model" that OpenMP SIMD code has to go through, and current LV is rather unclear about it
---- due to historical reasons ---- and I'm trying to resolve them one small step at a time.
See
2018 Jan 19
2
Does OpenMP hints bypass the vectorisation legality check in llvm
Hi all,
I am currently looking into how "#pragma omp for simd" is actually
recognized in llvm. To my knowledge, clang will parse it and set
metadata in IR to indicate this force-vectorization hint and later
optimization passes would read it and vectorize the marked loop.
Therefore, the loop should be vectorized even the compiler think it
might not be safe to do so?
So my
2018 Jan 23
0
MachineVerifier and undef
Thanks Krzysztof. That's very helpful - I was missing the distinction
between a register containing an undefined value and a register marked
as containing an undefined value. Cheers!
On 1/23/18, via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> Send llvm-dev mailing list submissions to
> llvm-dev at lists.llvm.org
>
> To subscribe or unsubscribe via the World Wide Web,
2017 Sep 04
2
[RFC] Polly Status and Integration
On Mon, Sep 4, 2017, at 20:49, Hal Finkel via llvm-dev wrote:
> [tying to original thread]
>
> On 09/04/2017 01:37 PM, Adve, Vikram Sadanand via llvm-dev wrote:
> > Hal, Tobias, et al. –
> >
> > I am strongly in favor of seeing a broader range of loop transformations, supported by strong dependence analysis, added to LLVM, and the Polly infrastructure seems to be by far
2018 Jan 09
1
RFC: [LV] any objections in moving isLegalMasked* check from Legal to CostModel? (Cleaning up LoopVectorizationLegality)
Thanks, Hal.
I plan to post a patch w/o HW Legality early bailout first. That should enable further discussion on where the initial very high cost for "illegal masked load/store/gather/scatter" should be coming from --- like should LoopVectorize provide it? Or should it be provided by TTI? I prefer the latter (TTI) but the first revision of the patch will intentionally do the former
2017 Sep 04
2
llvm-dev Digest, Vol 159, Issue 2
Hal, Tobias, et al. –
I am strongly in favor of seeing a broader range of loop transformations, supported by strong dependence analysis, added to LLVM, and the Polly infrastructure seems to be by far our best bet to make that happen. I have a couple of questions:
1) Integer constraint libraries like ISL (and Omega, which I used extensively in a previous project) are fundamentally solving
2016 Dec 12
0
[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
2016 Dec 08
6
[RFC] Enable "#pragma omp declare simd" in the LoopVectorizer
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
2017 Feb 01
0
[RFC] IR-level Region Annotations
Sent from my iPhone
> On Jan 31, 2017, at 7:27 PM, Tian, Xinmin <xinmin.tian at intel.com> wrote:
>
> Remember that, the prepare-phase is invoked in the FE or right after FE, inlining is not happening, that is why we don't call it "pass". Chandler made a good point for this case a long time back.
>
What I was describing is the inlining in the optimizer
2017 Feb 01
2
[RFC] IR-level Region Annotations
> On Jan 31, 2017, at 10:59 PM, Tian, Xinmin <xinmin.tian at intel.com> wrote:
>
>
> <>
> From: mehdi.amini at apple.com <mailto:mehdi.amini at apple.com> [mailto:mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>]
> Sent: Tuesday, January 31, 2017 9:03 PM
> To: Tian, Xinmin <xinmin.tian at intel.com <mailto:xinmin.tian at
2017 Feb 01
0
[RFC] IR-level Region Annotations
> On Jan 31, 2017, at 7:53 PM, Tian, Xinmin <xinmin.tian at intel.com> wrote:
>
> In this case, inliner is educated to add all local variables to the tag of enclosing parallel region, if there is enclosing parallel region.
So isn’t it a good example that shows that your intrinsic *cannot* be opaque and that IR passes need to be modified to handle not only the IR-region
2017 Feb 01
2
[RFC] IR-level Region Annotations
From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com]
Sent: Tuesday, January 31, 2017 9:03 PM
To: Tian, Xinmin <xinmin.tian at intel.com>
Cc: Sanjoy Das <sanjoy at playingwithpointers.com>; Adve, Vikram Sadanand <vadve at illinois.edu>; llvm-dev at lists.llvm.org; llvm-dev-request at lists.llvm.org
Subject: Re: [llvm-dev] [RFC] IR-level Region Annotations
On Jan 31,
2017 Feb 01
2
[RFC] IR-level Region Annotations
In this case, inliner is educated to add all local variables to the tag of enclosing parallel region, if there is enclosing parallel region.
In our icc implementation, it is even simple, as we have routine level symbol table, the inliner adds ”private” attribute to those local variables w/o checking enclosing scope, the parallelizer does check and use it.
Xinmin
From: mehdi.amini at apple.com
2014 Sep 29
2
[LLVMdev] Proposal for ""llvm.mem.vectorize.safelen"
Yes, I think the 2 outcomes are:
- the current spec is unclear and will be clarified
- in order to support safelen() and even the simd construct itself, LLVM will require infrastructure work to know when a lexically backwards dependence may have been introduced.
Jon
-----Original Message-----
From: Tian, Xinmin [mailto:xinmin.tian at intel.com]
Sent: Monday, September 29, 2014 10:43 AM
To:
2018 Jan 07
0
RFC: [LV] any objections in moving isLegalMasked* check from Legal to CostModel? (Cleaning up LoopVectorizationLegality)
On 01/05/2018 06:28 PM, Saito, Hideki wrote:
> Amara,
>
>> I support this direction
> Thanks for the support.
>
>> but are there actually any real world workloads where gather/scatter scalarisation would be worth it, on any micro-architecture? If we don’t have examples and the compile time cost is non-negligible then I think we’d still like to keep the early >bailouts in
2017 Feb 01
1
[RFC] IR-level Region Annotations
> On Jan 31, 2017, at 6:48 PM, Tian, Xinmin <xinmin.tian at intel.com> wrote:
>
> Let me try this.
>
> You can simply consider the prepare-phase (e.g. pre-privatization) were done in FE (actually a library can be used by multiple FEs at LLVM IR level), the region is run with 1 thread, region annotation (scope, single-entry-single-exit) as memory barrier conservatively
2017 Feb 01
0
[RFC] IR-level Region Annotations
Let me try this.
You can simply consider the prepare-phase (e.g. pre-privatization) were done in FE (actually a library can be used by multiple FEs at LLVM IR level), the region is run with 1 thread, region annotation (scope, single-entry-single-exit) as memory barrier conservatively for now (instead of checking individual memory dependency, aliasing via tags which is the actual
2018 Jan 06
2
RFC: [LV] any objections in moving isLegalMasked* check from Legal to CostModel? (Cleaning up LoopVectorizationLegality)
Amara,
>I support this direction
Thanks for the support.
>but are there actually any real world workloads where gather/scatter scalarisation would be worth it, on any micro-architecture? If we don’t have examples and the compile time cost is non-negligible then I think we’d still like to keep the early >bailouts in some form.’
It's not like I have specific application code in
2012 Oct 03
0
[LLVMdev] [RFC] OpenMP Representation in LLVM IR
Andrey,
While I think that it will be relatively easy to have the intrinsics
serve as code-motion barriers for other code that might be threads
sensitive (like other external function calls), we would need to think
through exactly how this would work. The easiest thing would be to make
the intrinsics have having unmodeled side effects, although we might
want to do something more intelligent.
2019 Jun 24
2
RFC: Interface user provided vector functions with the vectorizer.
For example, Type 2 case, scalar-foo used call by value while vector-foo used call by ref. The question Johannes is asking is whether we can decipher that after the fact, only by looking at the two function signatures, or need some more info (what kind, what's minimal)? I think we need to list up cases of interest, and for each vector ABI of interest, we need to work on the requirements and