similar to: cmpxchg on floats

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

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

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

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 all, I've decided the next step in atomics is the weak compare-and-exchange operation. As with the failure order, I'm going t outline the direction I'd like to take: 1. All cmpxchg instructions now return { iN, i1 } where the first value is what we got before (the loaded result), the second == 1 if an exchange took place. 1. "weak" is an optional modifier to the cmpxchg

# HG changeset patch # User Patrick Colp <Patrick.Colp@citrix.com> # Date 1249555177 -3600 # Node ID 684c8fc69d658d058246eb9edfc8eba187ae6f2c # Parent 68e8b8379244e293c55875e7dc3692fc81d3d212 hvm emul: fix cmpxchg emulation to use an atomic operation. Currently HVM cmpxchg emulation is done by doing a normal emulated write, which is not atomic. This patch changes it to use a cmpxchg

I'm working on getting the LLVM/projects/Test-Suite/UnitTest to compile for a target that I am developing. There is an example: AtomicOps, that uses calls to: __sync_fetch_and_add __sync_val_compare_and_swap __sync_lock_test_and_set These get converted into llvm IR operations like: atomicrmw cmpxchg Is there any way to keep these as function calls, as they are easier to map to the

On Fri, Apr 24, 2015 at 02:56:42PM -0400, Waiman Long wrote: > In the pv_scan_next() function, the slow cmpxchg atomic operation is > performed even if the other CPU is not even close to being halted. This > extra cmpxchg can harm slowpath performance. > > This patch introduces the new mayhalt flag to indicate if the other > spinning CPU is close to being halted or not. The

On Fri, Apr 24, 2015 at 02:56:42PM -0400, Waiman Long wrote: > In the pv_scan_next() function, the slow cmpxchg atomic operation is > performed even if the other CPU is not even close to being halted. This > extra cmpxchg can harm slowpath performance. > > This patch introduces the new mayhalt flag to indicate if the other > spinning CPU is close to being halted or not. The

On Thu, Apr 30, 2015 at 02:49:26PM -0400, Waiman Long wrote: > On 04/29/2015 02:11 PM, Peter Zijlstra wrote: > >On Fri, Apr 24, 2015 at 02:56:42PM -0400, Waiman Long wrote: > >>In the pv_scan_next() function, the slow cmpxchg atomic operation is > >>performed even if the other CPU is not even close to being halted. This > >>extra cmpxchg can harm slowpath

On Thu, Apr 30, 2015 at 02:49:26PM -0400, Waiman Long wrote: > On 04/29/2015 02:11 PM, Peter Zijlstra wrote: > >On Fri, Apr 24, 2015 at 02:56:42PM -0400, Waiman Long wrote: > >>In the pv_scan_next() function, the slow cmpxchg atomic operation is > >>performed even if the other CPU is not even close to being halted. This > >>extra cmpxchg can harm slowpath

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

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

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

In the pv_scan_next() function, the slow cmpxchg atomic operation is performed even if the other CPU is not even close to being halted. This extra cmpxchg can harm slowpath performance. This patch introduces the new mayhalt flag to indicate if the other spinning CPU is close to being halted or not. The current threshold for x86 is 2k cpu_relax() calls. If this flag is not set, the other spinning

On Wed, Apr 29, 2015 at 11:11 AM, Peter Zijlstra <peterz at infradead.org> wrote: > On Fri, Apr 24, 2015 at 02:56:42PM -0400, Waiman Long wrote: >> In the pv_scan_next() function, the slow cmpxchg atomic operation is >> performed even if the other CPU is not even close to being halted. This >> extra cmpxchg can harm slowpath performance. >> >> This patch

On 04/29/2015 02:11 PM, Peter Zijlstra wrote: > On Fri, Apr 24, 2015 at 02:56:42PM -0400, Waiman Long wrote: >> In the pv_scan_next() function, the slow cmpxchg atomic operation is >> performed even if the other CPU is not even close to being halted. This >> extra cmpxchg can harm slowpath performance. >> >> This patch introduces the new mayhalt flag to indicate if

I'm not sure if this will do everything that you want, but it controls at least some of these expansions at the Clang level: tools/clang/lib/Basic/Targets.cpp On Tue, May 14, 2013 at 3:46 PM, Dan <westdac at gmail.com> wrote: > > I'm working on getting the LLVM/projects/Test-Suite/UnitTest to compile > for a target that I am developing. > > There is an example: