similar to: RFC: Atomic LL/SC loops in LLVM revisited

Right now, the atomics implementation in clang is a bit of a mess. It has three basically completely distinct code-paths: There's the legacy __sync_* builtins, which clang lowers directly to atomic IR instructions. Then, the llvm atomic IR instructions themselves can sometimes emit libcalls to __sync_* library functions (which are basically undocumented, and users are often responsible for

On 12/11/2015 01:29 PM, James Y Knight wrote: > > On Fri, Dec 11, 2015 at 3:05 PM, Philip Reames via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> One open question I don't know the answer to: Are there any >> special semantics required from floating point stores which >> aren't met

I don't have much of substance to add, but I will say that I like the proposal (I too prefer Alternative A). When adding C11 atomic support for hexagon, I found it surprising that support for the __sync_* was implemented completely differently than the C11 atomics. On 1/27/2016 1:55 PM, James Knight via llvm-dev wrote: > Right now, the atomics implementation in clang is a bit of a

Hi, I've been looking at improving atomicrmw & cmpxchg code more, particularly on architectures using the load-linked/store-conditional model. The summary is that current expansion for cmpxchg seems to happen too late for LLVM to make meaningful use of the opportunities it provides. I'd like to move it earlier and express it in terms of a first-class pair of "load linked"

On 12/11/2015 12:05 AM, JF Bastien wrote: > On Fri, Dec 11, 2015 at 3:22 AM, Philip Reames via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Currently, we limit atomic loads and stores to either pointer or > integer types. I would like to propose that we extend this to > allow both floating point and vector types

Currently, we limit atomic loads and stores to either pointer or integer types. I would like to propose that we extend this to allow both floating point and vector types which meet the other requirements. (i.e. power-of-two multiple of 8 bits, and aligned) This will enable a couple of follow on changes: 1) Teaching the vectorizer how to vectorize unordered atomic loads and stores 2)

On 10 May 2014, at 13:53, Tim Northover <t.p.northover at gmail.com> wrote: > It doesn't make sense for everything though, particularly if you want > target-specific IR to simply not exist. What would you map ARM's > "ldrex" to on x86? This isn't a great example. Having load-linked / store-conditional in the IR would make a number of transforms related to

Hi Philip, On 29 May 2014 17:03, Philip Reames <listmail at philipreames.com> wrote: > I have some reservations about this proposal. I don't have anything > particularly concrete, but the idea of supporting both LL/SC and atomicrwm > in the IR concerns me from a complexity perspective. Well, I'll start by saying my particular optimisation use case looks like it's not

I'm working on a change to the layout algorithm, and I noted that test/CodeGen/ARM/cmpxchg-weak.ll was affected. Normally, that would be fine, but I noted that the layout changed the fallthrough from the success case to the failure case. I was surprised to see that the success case isn't annotated with a branch weight by AtomicExpandPass.cpp Would it make sense to annotate the success

On 14 June 2018 at 10:28, Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> * I'd like to see ARM+AArch64+Hexagon move away from the problematic >> expansion in IR and to have that code deleted from AtomicExpandPass. Are >> there any objections? > > I think it would be a great shame and I'd like to avoid it if at all > possible, though

Currently the AtomicExpandPass will lower the following IR: define i1 @foo(i32* %obj, i32 %old, i32 %new) { entry: %v0 = cmpxchg weak volatile i32* %obj, i32 %old, i32 %new _*release acquire*_ %v1 = extractvalue { i32, i1 } %v0, 1 ret i1 %v1 } to the equivalent of the following on AArch64: _*ldxr w8, [x0]*_ cmp w8, w1 b.ne .LBB0_3 // BB#1:

Seems reasonable. I'd note additionally that on some architectures, that the success block *must* be the fallthrough case (that is to say: you must not have any taken branches between the load-linked and store-conditional) in order to have an architectural guarantee that two such loops on different CPUs won't livelock against eachother. On Dec 12, 2016, at 12:30 PM, Kyle Butt via

Hello, I'm wondering how I can create an atomic load and add instruction for floating point values. If I use IRBuilder::CreateAtomicRMW() I get the error message: "atomicrmw operand must have integer type". I am using LLVM 3.4 and the only system I need to support is x86.

Greetings everyone, I am working on Aarch64 LSE out-of-line atomics support in LLVM, porting this GCC series: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg01034.html After local design experiments I've got some questions about upstream-suitable ways of implementation. More specifically: 1. Pass to expand atomics to library helper functions calls. These helpers test for the presence

Looking further during down time at the dev meeting today, it actually seems that PTX atom.* and red.* intrinsics map extremely naturally onto the LLVM atomicrmw and cmpxchg instructions. The biggest issue is that a subset of things expressible with these LLVM instructions do not trivially map to PTX, and the range of things naturally supported depends on the features of a given target. With

Forgive me if I'm missing something obvious, but it seems that a number of core instructions—I'm specifically running in to `atomicrmw`, `fence`, and `cmpxchg` at the moment—cannot be constructed from the C bindings, and are therefore also inaccessible to the OCaml bindings. There are opcodes for each of these in the llvm-c/Core.h, but there seems to be no way to construct them. Is there

On Mon, Oct 31, 2011 at 3:15 PM, Jonathan Ragan-Kelley <jrk at csail.mit.edu>wrote: > I notice that there is not currently any intrinsic support for atomics in > the PTX backend. Is this on the roadmap? Should it be as easy to add as it > seems (plumbing through just like the thread ID instructions, &c.)? The > obvious difference is that these ops have side effects. > It

I notice that there is not currently any intrinsic support for atomics in the PTX backend. Is this on the roadmap? Should it be as easy to add as it seems (plumbing through just like the thread ID instructions, &c.)? The obvious difference is that these ops have side effects. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type:

Alex, ping? There was a thread about moving Risc-V out of experimental but I think it didn't go anywhere? Separately, do the listed patches sound okay for merging? Thanks, Hans On Fri, Jan 25, 2019 at 4:40 PM Bruce Hoult <brucehoult at sifive.com> wrote: > > In https://llvm.org/svn/llvm-project/llvm/branches/release_80 I find > that RISCV is still in

Hi: In our frontend we are attempting to build a lock mechanism without using system apis like pthreads and whatnot for internal reasons. In order to achieve this we are now creating a int32 type GV, and then use atomic load/store and comparisons. The generated IR looks like the following: ``` @Flag = private global i32 0, align 4 %0 = load atomic i32, i32* @Flag acquire, align 4 %1 = icmp eq