search for: __builtin_assume

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

...ot increase the use count at all (and keep everything else working), but what we can do is make sure the uses in "assumptions" are easy to spot, thus filter. This is not the case right now because of the additional instructions we need to make the values boolean. Even if you have `__builtin_assume(ptr);` the `ptr` use will not be the `llvm.assume` call but a `icmp`. C) The side-effect avoidance. `__assume`, `__builtin_assume`, `__builtin_assume_aligned`, and OpenMP `omp assume` are all defined to not evaluate their argument, thus to not cause the side effects that the evaluation of...

...ep everything else > > working), but what we can do is make sure the uses in "assumptions" > > are easy to spot, thus filter. This is not the case right now because > > of the additional instructions we need to make the values boolean. > > Even if you have `__builtin_assume(ptr);` the `ptr` use will not be > > the `llvm.assume` call but a `icmp`. > > > > C) The side-effect avoidance. > > `__assume`, `__builtin_assume`, `__builtin_assume_aligned`, and OpenMP > > `omp assume` are all defined to not evaluate their argument, thus to &gt...

...I was thinking this was going to be done with an > assert (or a special no code generating assert). Just gen up assert > (i != 0); and put it in anytime it is true. The optimizers in the > fulness of time would the recognize and propagate this information. Can't you implement __builtin_assume(cond) to codegen to something like: %cond = i1 ... br i1 %cond, label %always, label %never never: unreachable always: Then in assert.h: #ifdef NDEBUG # define assert(cond) __builtin_assume((cond)) #else # define assert(cond) ... #endif — Gordon

...> working), but what we can do is make sure the uses in "assumptions" > >>> are easy to spot, thus filter. This is not the case right now because > >>> of the additional instructions we need to make the values boolean. > >>> Even if you have `__builtin_assume(ptr);` the `ptr` use will not be > >>> the `llvm.assume` call but a `icmp`. > >>> > >>> C) The side-effect avoidance. > >>> `__assume`, `__builtin_assume`, `__builtin_assume_aligned`, and OpenMP > >>> `omp assume` are all defined to...

...a follow-up to several older ones, on invariants in LLVM. Fundamentally, invariants are conditions that the optimizer is allowed to assume will be valid during the execution of the program. Many other compilers support a concept like this, MSVC's __assume, for example. GCC has a builtin called __builtin_assume_aligned which also neatly falls into this class. In my initial patches, I've named the associated IR-level intrinsic @llvm.invariant(i1) (maybe it should be @llvm.assume, etc. -- please feel free to express an opinion). I'll attempt to highlight the primary issue involved with a simple ex...

> Can't you implement __builtin_assume(cond) to codegen to something like: > > %cond = i1 ... > br i1 %cond, label %always, label %never > never: > unreachable > always: The code generators will remove the branch to %never. I already tried this :) What would work is to define an llvm.abort intrinsic, and do: %...

On Oct 22, 2008, at 3:28 PM, Paul Biggar wrote: > As part of our PHP compiler (phpcompiler.org), it would be great to be > able to annotate our generated C code with, for example, (var != > NULL), or (var->type == STRING), and have that information passed > around (esp interprocedurally at link-time) by the LLVM optimizers. For some odd reason I was thinking this was going to be

Hi everybody, I see a missed optimization opportunity in LLVM that GCC catches and I'd love to hear community's input. Here's the original C code: 1 char arr[2]; 2 char *get(unsigned ind) { 3 if (ind >= 1) { 4 return 0; 5 } 6 return &(arr[ind]); 7 } The variable `ind` is unsigned so, based on the comparison, if it is not greater or equals to one, than it is

Hi Tim and Alex Thanks for your replies. So just to make it clear for me: does this imply that there’s indeed no way on the current version to tell the compiler or Clang to optimize this? Thanks, Joan > On 8 Aug 2019, at 18:30, Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, 8 Aug 2019 at 17:08, Alex Brachet-Mialot via llvm-dev > <llvm-dev at

...nvariants in LLVM. Fundamentally, invariants are conditions that > > the optimizer is allowed to assume will be valid during the > > execution of the program. Many other compilers support a concept > > like this, MSVC's __assume, for example. GCC has a builtin called > > __builtin_assume_aligned which also neatly falls into this class. > First of all, thank you for working on this! I'm thrilled to see > progress being made here. > > > > In my initial patches, I've named the associated IR-level intrinsic > > @llvm.invariant(i1) (maybe it should be @l...

Hi, I'm interested in whether or not there is a way of providing source-level annotations to help LLVM with optimizations, similar to VisualC++'s __assume facility (http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx). As part of our PHP compiler (phpcompiler.org), it would be great to be able to annotate our generated C code with, for example, (var != NULL), or (var->type ==

...on impacts the kinds of analysis we can perform on the program. In Polly, we care about dependence analysis, so the examples here will focus on that particular problem. Let us consider an array indexing operation of the form: ```cpp int ex1(int n, int m, B[n][m], int x1, int x2, int y1, int y2) { __builtin_assume(x1 != x2); __builtin_assume(y1 != y2); B[x1][y1] = 1; printf("%d", B[x2][y2]); exit(0); } ``` One would like to infer that the array indices _interpreted as tuples_ `(x1, y1)` and `(x2, y2)` do not have the same value, due to the guarding asserts that `x1 != x2` and `y1 != y2`. As a...

On Oct 22, 2008, at 5:36 PM, Gordon Henriksen wrote: > Can't you implement __builtin_assume(cond) to codegen to something > like: > %cond = i1 ... > br i1 %cond, label %always, label %never > never: > unreachable > always: The thing I don't like about this, is that this has conditional branches all over the place, which break up basic blocks, which, if you...

...he program. In Polly, we care about >> dependence analysis, so the examples here will focus on that particular problem. >> >> Let us consider an array indexing operation of the form: >> ```cpp >> int ex1(int n, int m, B[n][m], int x1, int x2, int y1, int y2) { >> __builtin_assume(x1 != x2); >> __builtin_assume(y1 != y2); >> B[x1][y1] = 1; >> printf("%d", B[x2][y2]); >> exit(0); >> } >> ``` >> >> One would like to infer that the array indices _interpreted as tuples_ >> `(x1, y1)` and `(x2, y2)` do not have the s...

...n the program. In Polly, we care about > dependence analysis, so the examples here will focus on that particular problem. > > Let us consider an array indexing operation of the form: > ```cpp > int ex1(int n, int m, B[n][m], int x1, int x2, int y1, int y2) { > __builtin_assume(x1 != x2); > __builtin_assume(y1 != y2); > B[x1][y1] = 1; > printf("%d", B[x2][y2]); > exit(0); > } > ``` > > One would like to infer that the array indices _interpreted as tuples_ > `(x1, y1)` and `(x2, y2)` do not have the s...

...care about >>> dependence analysis, so the examples here will focus on that particular problem. >>> >>> Let us consider an array indexing operation of the form: >>> ```cpp >>> int ex1(int n, int m, B[n][m], int x1, int x2, int y1, int y2) { >>> __builtin_assume(x1 != x2); >>> __builtin_assume(y1 != y2); >>> B[x1][y1] = 1; >>> printf("%d", B[x2][y2]); >>> exit(0); >>> } >>> ``` >>> >>> One would like to infer that the array indices _interpreted as tuples_ >>> `(x1, y...

On Oct 22, 2008, at 10:45 PM, Duncan Sands wrote: >> Can't you implement __builtin_assume(cond) to codegen to something >> like: >> >> %cond = i1 ... >> br i1 %cond, label %always, label %never >> never: >> unreachable >> always: > > The code generators will remove the branch to %never. > I already tried this :) What would work is...

...lly expected" values that the programmer would provide, sparsely, on different scalars of a function. I am not sure if the __builtin_expect was meant for this purpose. It is nicely SSA friendly (it returns a value on which we can "attach" the expectation) but maybe something akin to __builtin_assume is preferable? Basically: %b = i64 call @llvm.expect(i64 %a, i64 16) %c = i64 call something(%b) %d = i64 call something(%a) Can be easily transformed into: %b = i64 call @llvm.expect(i64 %a, i64 16) %c = i64 call something_that_handle_16_great(%b) %d = i64 call something(%a) But it is harder...

...e analysis, so the examples here will focus on that particular problem. > > > > > > Let us consider an array indexing operation of the form: > > > ```cpp > > > int ex1(int n, int m, B[n][m], int x1, int x2, int y1, int y2) { > > > __builtin_assume(x1 != x2); > > > __builtin_assume(y1 != y2); > > > B[x1][y1] = 1; > > > printf("%d", B[x2][y2]); > > > exit(0); > > > } > > > ``` > > > > > > One would like...