similar to: [LLVMdev] cmpxchg instruction with pointer operands

Thanks for reviving this. I completely forgot the details but I resolved this problem. Looking though the code, seems I forked RewriteStatepointsForGC pass, and change it to adding 'gc-livevars' bundle to the call/invoke inst after finding the livevars, instead of changing it to StatepointCall intrinsic. On Wed, Nov 14, 2018 at 11:48 AM Philip Reames <listmail at philipreames.com>

Hi Team, I'm working on a new pure functional language and I'm trying to add GC support for that. Because all vars are immutable, the IR that my frontend generates are all register based, i.e. no alloca, and no readmem, writemem unless accessing/constructing structs. If I use the traditional GC with gcroot intrinsic, it will need to emit more code for liveness tracking, storing the IR

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

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:

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

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

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

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

Dear Prof: My name is Chuan.I from Malaysia.I am a beginner for R.I need favor for Prof. This is my data: y<-c(52,55,61,66,70,61,64,73,63,59,55,90,109,85,69,72,62,59,68,113,144,104,66,73,63,58,71,122,154,106,70,69,67,61,68,104,126,88,68,70,79,65,60,70,77,68,58,75,85,71,64,59,55,61,65,83,87,79,69,68,65,76,78,94) and I form it into matrix as below: [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8]

Dear All. I am Chuan. I am beginner for R.I facing some problem in remove element from vector.I have a vector with size 238 element as follow(a part) [1] 0 18 24 33 44..................................[238] 255 Let the vector label as "x",I want remove element "0" and "255".I try use such function: x[x>0 & x<255] However, I am fail since same results

Hi Matthias, Sorry for the late reply. Yes, you are correct, I do have optnone attribute on my function. I did pass -O0 to the tools. For your information, my invocations are as below: clang --target=mips-unknown-linux -mips32 test.c -emit-llvm -S llc -O0 -march=mips -mcpu=mips32 test.ll -o test.s Based on the generated .ll file, there is optnone attribute on the function, i

Running llc with '-verify-machineinstrs' may tell you which instruction break the SSA form. Ruiling From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of jin chuan see via llvm-dev Sent: Monday, September 11, 2017 10:02 AM To: Matthias Braun <mbraun at apple.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Live Register Spilling Sorry about the

> On Sep 13, 2017, at 9:03 PM, jin chuan see via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi All, > > Thanks for the reply. I managed to identify and fixed a few errors in my implementation. > > However, there are a few errors that i am not sure what is it indicating. > For starters, i think i should explain what i am trying to achieve. > > I am