search for: assume_safety

...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 "vectorize(assume_safety)" (which asserts that no loop-carried dependencies are present). The good news is that, in conversations I've had with Intel, an openness to making these semantics more concrete has been expressed. I think it would be very useful to have ivdep in Clang, but only after we nail down the sema...

...;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 better threading structure to the replies. * Ivdep: Is clang loop vectorize(assume_safety) equivalent to ivdep? To what extent do the semantics of ivdep need to be modified for Clang to create an equally “useful pragma”? To what extent would it be helpful to have this pragma in Clang? There is a fundamental problem with the way that ivdep is defined by Intel's current documentati...

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

...iler 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 of d's extent). > > You can inform LLVM that it is safe to vectorize anyway by adding a pragma, like this: > > #pragma clang loop vectorize(assume_safety) I don’t think it would be enough (due to current limitations of vectorizer). The following expression will be vectorizable: res[i] = (p[i] == 0) ? (res[i] + c[i]) : (res[i] + d[i]); // Note “+ c[i]” This way, vectorizer deals with similar expressions in both true and false branc...

...oalias_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 vectorize(assume_safety) > for (int i = 0; i < n; i+=1) { > (void)A[0]; > } > > I hope it is obvious that the loop is parallel and can be vectorized, > but A[0] from iteration 0 will alias with A[0] from iteration 1. > Replace `0` by `i*c` where c is a variable that can be 0 at runtime to > ma...

...larger than EpilogVF. No need to introduce again any potential aliasing, wrapping or whatnot checks, even if this redundancy can later be eliminated, if instead this vectorizability property could be recorded somehow. Similar to having annotated the remainder loop with “#pragma clang loop vectorize(assume_safety)”, except that this vectorizability property does not hold when reaching the remainder loop along the other path – that which fails these checks for the main loop... Ayal. -Hal Michael On Mon, Feb 27, 2017 at 10:11 AM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wr...

...he 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 vectorize(assume_safety) > >> for (int i = 0; i < n; i+=1) { > >> (void)A[0]; > >> } > >> > >> I hope it is obvious that the loop is parallel and can be vectorized, > >> but A[0] from iteration 0 will alias with A[0] from iteration 1. > >> Replace `0` by...

...;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 better threading structure to the replies. * Ivdep: Is clang loop vectorize(assume_safety) equivalent to ivdep? To what extent do the semantics of ivdep need to be modified for Clang to create an equally “useful pragma”? To what extent would it be helpful to have this pragma in Clang? There is a fundamental problem with the way that ivdep is defined by Intel's current documentati...

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

...== 0) >          return nullptr; > > This changes the order of access groups when merging them. > Same background: Access groups are used to mark that a side-effect > (e.g. memory access) does not limit the parallelization of a loop, > added by e.g. #pragma clang loop vectorize(assume_safety). Therefore a > loop can be assumed to be parallelizable without further dependency > analysis if all its side-effect instructions are marked this way (and > has no loop-carried scalar dependencies). > An access group represents the instructions marked for a specific > loop. A si...

...at hand. I understand your point, but I think that you're assuming too much about the semantics of the pragmas. I believe that our current vectorization pragma clauses demonstrate the philosophy we should follow with other loop pragmas in this sense: We have vectorize(enable) and vectorize(assume_safety). The latter one does indeed just vectorize the loop without requiring dependency analysis, but the vectorize(enable) clause instructs the vectorizer to vectorize the loop (overriding/loosening some of the cost model constraints), but still uses the dependency analysis and generates runtime che...

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

...understand your point, but I think that you're assuming too much about the > semantics of the pragmas. I believe that our current vectorization pragma > clauses demonstrate the philosophy we should follow with other loop pragmas > in this sense: We have vectorize(enable) and vectorize(assume_safety). The > latter one does indeed just vectorize the loop without requiring dependency > analysis, but the vectorize(enable) clause instructs the vectorizer to > vectorize the loop (overriding/loosening some of the cost model > constraints), but still uses the dependency analysis and gener...

...ups1); if (Union.size() == 0) return nullptr; This changes the order of access groups when merging them. Same background: Access groups are used to mark that a side-effect (e.g. memory access) does not limit the parallelization of a loop, added by e.g. #pragma clang loop vectorize(assume_safety). Therefore a loop can be assumed to be parallelizable without further dependency analysis if all its side-effect instructions are marked this way (and has no loop-carried scalar dependencies). An access group represents the instructions marked for a specific loop. A single instruction can be paral...

...r point, but I think that you're assuming too much about the > > semantics of the pragmas. I believe that our current vectorization pragma > > clauses demonstrate the philosophy we should follow with other loop pragmas > > in this sense: We have vectorize(enable) and vectorize(assume_safety). The > > latter one does indeed just vectorize the loop without requiring dependency > > analysis, but the vectorize(enable) clause instructs the vectorizer to > > vectorize the loop (overriding/loosening some of the cost model > > constraints), but still uses the dependenc...

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