search for: assume_safeti

> There is a fundamental problem with the way that ivdep is defined by Intel's current documentation, at least for C/C++. As you note in your Google doc, it essentially says that the optimizer may ignore loop-carried dependencies except for those dependencies it can definitely prove are present. These are not semantics that any other compiler can actually replicate, and is not equivalent to

On 8/8/19 2:03 PM, Hal Finkel wrote: Hi, First, as a high-level note, you posted a link to a Google doc, and at the end of the Google doc, you have a list of questions that you'd like answered. In the future, please put the questions directly in the email. For one thing, more people will read your email than will open your Google doc. Second, having the questions in the email should allow a

Hello all, We are students from Indian Institute of Technology(IIT), Hyderabad, we would like to propose the addition of the following pragmas in LLVM that aide in (or possibly increase the scope of) vectorization in LLVM (in comparison with other compilers). 1. ivdep 2. Nontemporal 3. [no]vecremainder 4. [no]mask_readwrite 5. [un]aligned Could you please

Hi, > On Apr 22, 2016, at 8:27 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Rob, > > The problem here is that the d[i] array is only conditionally accessed, and so we can't if-convert the loop body. The compiler does not know that d[i] is actually dereferenceable for all i from 0 to 15 (the array might be shorter and p[i] is 0 for i past the end

Would you guys be open to supporting a new hint with the right semantics, like e.g. llvm.loop.noalias_accesses?! I would need to find support in clang however and the main point of support would be the loop unroller behaving as stated in the OP. On Thu, May 14, 2020 at 3:04 PM Michael Kruse <llvmdev at meinersbur.de> wrote: > Trivial example: > > #pragma clang loop

On 02/27/2017 12:41 PM, Michael Kuperstein wrote: There's another issue with re-running the vectorizer (which I support, btw - I'm just saying there are more problems to solve on the way :-) ) Historically, we haven't even tried to evaluate the cost of the "constant" (not per-iteration) vectorization overhead - things like alias checks. Instead, we have hard bounds - we

Skipping the clang question for now, this had to be a loop pragma of some kind. One step back: what we really need is a way to express that memory accesses between iterations can be re-ordered. The code that's being compiled _is_ noalias, but we don't _have_ to use noalias semantics, e.g. loop parallel semantics are sufficient. What's missing is a way to express that past the llvm

vecremainder/novecremainder: Should the pragma simply call the vectorizer to attempt to vectorize the remainder loop, or should the vectorizer use a different method? > > Something like that. There were patches posted at some point to enable tail-loop vectorization. At this point, I imagine that you'd construct a VPlan with the vectorized tail. Yep, committed in

Hi. I'm trying to vectorize the following piece of code with Loop Vectorizer (from LLVM distribution Nov 2015), but no vectorization takes place: int *Test(int *res, int *c, int *d, int *p) { int i; for (i = 0; i < 16; i++) { //res[i] = (p[i] == 0) ? c[i] : d[i]; res[i] = (p[i] == 0) ? res[i] : res[i] + d[i];

Hi llvm-dev! We are doing some fuzzy testing using C program generators, and one question that came up when generating a program with both floating point arithmetic and loop pragmas was; Is the loop vectorizer really allowed to vectorize a loop when it can't prove that it is safe to reorder fp math, even if there is a loop pragma that hints about a preferred width. When reading here

This is interesting! So are you saying that loop.parallel_accesses strictly loop parallel, and says nothing about aliasing? I see, I guess we may have been "abusing" the hint and re-purposed it. But isn't llvm's vectorizer using loop.parallel_accesses to vectorize loops including vectorize memory accesses that if you ignore loop-carried dependencies, usually means effectively

void test_copy_vec(const short* restrict src, short* restrict res, int N) { __builtin_assume( (N > 1) && (N%2 == 0) ); #pragma clang loop vectorize(enable) vectorize_width(2) interleave_count(1) for (int j=0; j<N; ++j) *res++ = *src++; } If I use __builtin_assume(N>1) then llvm knows the loop will execute and not check for (j <= 0), but I can't seem to get it to

Am Mi., 24. Juni 2020 um 10:12 Uhr schrieb David Blaikie <dblaikie at gmail.com>: > > As mentioned in the Differential, generating the tests automatically > > will lose information about what actually is intended to be tested, > > Agreed - and I didn't mean to suggest tests should be automatically > generated. I work pretty hard in code reviews to encourage tests to

On 7/1/20 12:40 AM, Michael Kruse via llvm-dev wrote: > To illustrate some difficulties with FileCheck, lets make a > non-semantic change in LLVM: > >     --- a/llvm/lib/Analysis/VectorUtils.cpp >     +++ b/llvm/lib/Analysis/VectorUtils.cpp >     @@ -642,8 +642,8 @@ MDNode *llvm::uniteAccessGroups(MDNode > *AccGroups1, MDNode *AccGroups2) { >          return AccGroups1;

Hi, Johannes, Thanks for writing this. I certainly think you have the right idea in terms of the desired end state and modular design. On 09/19/2017 07:33 PM, Johannes Doerfert wrote: > Hi Hal, Tobias, Michael, and others, > > I'd like to add my view (and a proposal) to this discussion and I > apologize directly for doing this so late*. I also want to apologize > because this

There's another issue with re-running the vectorizer (which I support, btw - I'm just saying there are more problems to solve on the way :-) ) Historically, we haven't even tried to evaluate the cost of the "constant" (not per-iteration) vectorization overhead - things like alias checks. Instead, we have hard bounds - we won't perform alias checks that are "too

Hi Hal, On 09/22, Hal Finkel wrote: > Hi, Johannes, > > Thanks for writing this. I certainly think you have the right idea in terms > of the desired end state and modular design. Thanks for the feedback! > On 09/19/2017 07:33 PM, Johannes Doerfert wrote: > >Hi Hal, Tobias, Michael, and others, > > > >I'd like to add my view (and a proposal) to this

The test as written is fragile because it requires a certain ordering. If the output order is not important, use CHECK-DAG rather than CHECK. This would be a failure to understand the testing tool. My experience, over a 40-year career, is that good software developers are generally not very good test-writers. These are different skills and good testing is frequently not taught. It’s easy to

On Tue, Sep 26, 2017, at 00:03, Johannes Doerfert wrote: > Hi Hal, > > On 09/22, Hal Finkel wrote: > > Hi, Johannes, > > > > Thanks for writing this. I certainly think you have the right idea in terms > > of the desired end state and modular design. > > Thanks for the feedback! > > > > On 09/19/2017 07:33 PM, Johannes Doerfert wrote: >

Hi Hal, Tobias, Michael, and others, I'd like to add my view (and a proposal) to this discussion and I apologize directly for doing this so late*. I also want to apologize because this email is long, contains various technical details and also argumentations that might need more justification. However, I am happy to provide further information (and/or examples) to explain my views if