similar to: [LLVMdev] RFC: add "cmpxchg weak" to LLVM IR

Hi Chandler, > So, I see where you're going here, but I'm curious -- why not just switch > ATOMIC_CMP_SWAP to have a second i1 value, and still be strong? Is this > *just* to support expanding? I wonder if that's really useful rather than > just lowering it directly on the various targets.... I tried that originally, but quickly got into murky waters with all the targets

On Fri, Mar 25, 2016 at 02:22:11PM -0400, Jan Vesely wrote: > Hi Tom, Matt, > > I'm working on a project that needs few coherent atomic operations (HSA > mode: load, store, compare-and-swap) for std::atomic_uint in HCC. > > the attached patch implements atomic compare and swap for SI+ > (untested). I tried to stay within what was available, but there are > few issues

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:

Hi Tom, Matt, I'm working on a project that needs few coherent atomic operations (HSA mode: load, store, compare-and-swap) for std::atomic_uint in HCC. the attached patch implements atomic compare and swap for SI+ (untested). I tried to stay within what was available, but there are few issues that I was unsure how to address: 1.) it currently uses v2i32 for both input and output. This

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

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 10 May 2014, at 18:14, Tim Northover <t.p.northover at gmail.com> wrote: >> The easiest solution would be to extend the cmpxchg instruction with a >> weak variant. It is then trivial to map load, modify, weak-cmpxchg to >> load-linked, modify, store-conditional (that is what weak cmpxchg was >> intended for in the C[++]11 memory model). > > That would

Hi all, The C++11 (& C11) compare_exchange functions with explicit memory order allow you to specify two sets of semantics, one for when the exchange actually happens and one for when it fails. Unfortunately, at the moment the LLVM IR "cmpxchg" instruction only has one ordering, which means we get sub-optimal codegen. This probably affects all architectures which use

On 10 May 2014, at 16:18, Tim Northover <t.p.northover at gmail.com> wrote: > Actually, I really agree there. I considered it recently, but decided > to leave it as an intrinsic for now (the new IR expansion pass happens > after most optimisations so there wouldn't be much benefit, but if we > did it earlier and the mid-end understood what an ldrex/strex meant, I > could

On Sat, Aug 22, 2020 at 10:59:51AM +0200, Nicolai Hähnle wrote: > On Sat, Aug 22, 2020 at 2:52 AM Joerg Sonnenberger via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Aug 21, 2020 at 11:51:18PM +0200, Nicolai Hähnle wrote: > > > On Tue, Aug 18, 2020 at 1:27 AM Joerg Sonnenberger via llvm-dev > > > <llvm-dev at lists.llvm.org> wrote:

On 18 June 2014 17:10, Sean Silva <chisophugis at gmail.com> wrote: >> >> Do others agree that this is the case or at least that this would be a >> >> reasonable balance? >> > IMO it's easier to be compatible on .ll level, no? >> >> That is not my experience with the bitcode format. The way the API is >> structured makes it really easy

On Fri, Aug 21, 2020 at 11:51:18PM +0200, Nicolai Hähnle wrote: > On Tue, Aug 18, 2020 at 1:27 AM Joerg Sonnenberger via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > On Fri, Aug 14, 2020 at 10:42:02AM -0700, JF Bastien via llvm-dev wrote: > > > We (C, C++, and LLVM) are generally moving towards supporting FP as a > > > first-class thing with all atomic

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

> I am planning in doing in IR, but with target specific-passes (such as X86ExpandAtomicPass) > that just share some of the code This would more normally be done via target hooks in LLVM, though the principle is sound. > But it must be target-dependent as for example on Power a > seq_cst store has a fence before it, while on ARM it has a fence > both before and after it (per

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 LLVM-dev, when working on MLIR-to-LLVM-IR conversion, I noticed that it is possible to programmatically construct a cmpxchg instruction operating on floats (or actually any type since there is no assertion on pointer element type here https://github.com/llvm/llvm-project/blob/9c2e708f0dc547d386ea528450a33ef4bd2a750b/llvm/lib/IR/Instructions.cpp#L1501), but LangRef specifies that only integers

On Fri, Aug 14, 2020 at 10:42:02AM -0700, JF Bastien via llvm-dev wrote: > We (C, C++, and LLVM) are generally moving towards supporting FP as a > first-class thing with all atomic operations †, including cmpxchg. It’s > indeed *usually* specified as a bitwise comparison, not a floating-point > one, although IIRC AMD has an FP cmpxchg. Similarly, some of the > operations are allowed

cmpxchg only support exchange on int operands, but pointer values can be very useful here, e.g. stack<T> in a linked-list, the top can be atomic<Node<T>*>. in clang++, cmpxchg operations on atomic<T*> are bitcasted i64 and do the operation, which is ugly. Any reason or concern why cmpxchg doesn't support pointer operands? Thanks -------------- next part

We've relaxed `atomicrmw xchg` to support floating point types but not cmpxchg -- the cmpxchg comparison behavior is not a floating point comparison, so that would be potentially misleading. I'd say adding the assertion is a good idea. Cheers, Nicolai On Thu, Aug 13, 2020 at 10:59 PM Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Does the code generator

Quoting Tim Northover <t.p.northover at gmail.com>: > On 24 April 2015 at 13:53, Tyler Denniston <tyler at csail.mit.edu> wrote: >> 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". > >