search for: __builtin_assume_aligned

On Thu, Sep 12, 2013 at 4:52 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > If we only try to solve your immediate problem of > > builtin_assume_aligned, isn't that good enough for now? > > The thing that most concerns me about __builtin_assume_aligned and this > scheme is the control dependencies. In gcc, it is the return value of the > intrinsic that carries the alignment guarantee, and I think that this makes > a lot of sense. Consider something like this: > > void foo(double *x) { > if (check_if_x_is_special(&global_st...

...bute__(aligned(X)) that can be set on a type in C/C++. It is being used when generating the load / stores / memcpy / ... but is lost with respect to the type's attribute. In many a case this could help various analysis or transforms to provide more accurate results when such a type is used. The __builtin_assume_aligned could be an way to solve this. Cheers, -- Arnaud On Tue, Mar 25, 2014 at 4:22 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Frank Winter" <fwinter at jlab.org> > > To: llvmdev at cs.uiuc.edu > > Sent: Tuesday, Mar...

...*,i32, i32) > > > I don't know if it's better to use strings or enums. I'm not a > meta-data designer. > > > If we only try to solve your immediate problem of > builtin_assume_aligned, isn't that good enough for now? The thing that most concerns me about __builtin_assume_aligned and this scheme is the control dependencies. In gcc, it is the return value of the intrinsic that carries the alignment guarantee, and I think that this makes a lot of sense. Consider something like this: void foo(double *x) { if (check_if_x_is_special(&global_state)) { y = __builtin_ass...

...de7297abe2e8fa782682168989c70e3cb34a5c However, it seems that the ValueTracking cannot understand the new format. As an example, consider compilation of the following reproducer with clang-11 (old assume format) and clang-trunk (assume bundles): #include <stdint.h> int foo(int *p) { __builtin_assume_aligned(p, 32); return ((intptr_t) p) & 4; } clang-11 (https://godbolt.org/z/xGh1e4) computes the returned value statically: ret i32 0 clang-trunk (https://godbolt.org/z/1jWe5j) fails to optimize the code: %3 = ptrtoint i32* %0 to i64 %4 = trunc i64 %3 to i32 %5 = and i32 %4, 4 ret...

...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 @llvm.assu...

On 03/25/2014 10:08 AM, Krzysztof Parzyszek wrote: > On 3/25/2014 8:53 AM, Frank Winter wrote: >> >> One can see that if the initial alignment of the pointee of %arg0 was 32 >> bytes and since the vectorizer operates on a loop with a fixed trip >> count of 4 and the size of double is 8 bytes, the vector loads and >> stores could be ideally aligned with 32 bytes

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

...igner. If we only try to solve your immediate problem of builtin_assume_aligned, isn't that good enough for now? Are you concerned about generalizing this to builtin_assume? >> On the other hand, when I started down this road I was motivated by a >> desire to implement support for __builtin_assume_aligned. I would >> still like to do this, or something like this to get equivalent >> functionality. The idea of metadata references seems like it might >> work well for alignment assumptions, as a restricted special case. >> Maybe something like this: >> >> tail call...

...0e3cb34a5c > > However, it seems that the ValueTracking cannot understand the new format. As an example, consider compilation of the following reproducer with clang-11 (old assume format) and clang-trunk (assume bundles): > > #include <stdint.h> > int foo(int *p) { > __builtin_assume_aligned(p, 32); > return ((intptr_t) p) & 4; > } > > clang-11 (https://godbolt.org/z/xGh1e4) computes the returned value statically: > > ret i32 0 > > clang-trunk (https://godbolt.org/z/1jWe5j) fails to optimize the code: > > %3 = ptrtoint i32* %0 to i64 > %...

...language encoded in a string with some syntax for substitution values; maybe something like: !invariant1 = !{ !"(eq (urem #1, 48), 0)", i32 %value} > > > > > On the other hand, when I started down this road I was motivated by a > desire to implement support for __builtin_assume_aligned. I would > still like to do this, or something like this to get equivalent > functionality. The idea of metadata references seems like it might > work well for alignment assumptions, as a restricted special case. > Maybe something like this: > > tail call void @llvm.assume.aligne...

Hello again, In discussing my proposed patches for supporting alignment assumptions (for supporting __builtin_assume_aligned; see http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121126/157659.html), Chandler and I have started discussing an infrastructure for declaring invariants in the IR for use by the optimizer. The basic idea is to introduce a new intrinsic: void @llvm.invariant(i1 %cond) which declare...

...ing my thoughts here effectively. Let me know if this would be a good thing for us to talk about in person at some point? (Hopefully it doesn't need to wait for the dev mtg...) > > On the other hand, when I started down this road I was motivated by a > desire to implement support for __builtin_assume_aligned. I would still > like to do this, or something like this to get equivalent functionality. > The idea of metadata references seems like it might work well for alignment > assumptions, as a restricted special case. Maybe something like this: > > tail call void @llvm.assume.aligned(meta...

...ot, 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 the argument would otherwise imply. The way we implement this restriction is by not emitting the argument expression in IR if it might cause a side effect. W...

...working assumption that if the invariant is worth having, then it is worth carrying as a dependency of the values it constrains. This may not be true, but I think is a viewpoint worth evaluating. On the other hand, when I started down this road I was motivated by a desire to implement support for __builtin_assume_aligned. I would still like to do this, or something like this to get equivalent functionality. The idea of metadata references seems like it might work well for alignment assumptions, as a restricted special case. Maybe something like this: tail call void @llvm.assume.aligned(metadata !{i32* %ptr}, i32 1...

...mix ephemeral expressions with program logic and impractical to make it transparent to optimizations. Not the end of the world though, and I’ll listen to any strong arguments to the contrary. > On the other hand, when I started down this road I was motivated by a desire to implement support for __builtin_assume_aligned. I would still like to do this, or something like this to get equivalent functionality. The idea of metadata references seems like it might work well for alignment assumptions, as a restricted special case. Maybe something like this: > > tail call void @llvm.assume.aligned(metadata !{i32* %p...

...; > 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 the argument would > > otherwise imply. The way we implement this restriction is by not > > emitting the argument expression in...

...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 the argument would > >>> otherwise imply. The way we implement this restriction is by not > >>> emi...

On Feb 22, 2013, at 6:28 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Andrew Trick" <atrick at apple.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "llvmdev at cs.uiuc.edu List" <llvmdev at cs.uiuc.edu>, "Michele Scandale" <michele.scandale at gmail.com> >>

----- Original Message ----- > From: "Andrew Trick" <atrick at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvmdev at cs.uiuc.edu List" <llvmdev at cs.uiuc.edu>, "Michele Scandale" <michele.scandale at gmail.com> > Sent: Friday, February 8, 2013 1:52:55 PM > Subject: llvm.meta (was Rotated loop