similar to: [LLVMdev] atomicrmw

All, I was wondering if the following operations could be implemented atomically in LLVM (a la AtomicRMW): Multiplication, Division, Remainder, Bit Shifting, or Logical Not (this could be implemented by xor with a value of all 1's). Is there a reason implementation-wise that they are not there? Additionally, would it be possible to create something similar to AtomicRMW that returned the new

Hi there, I am having a problem. It looks like this: Feb 16 15:01:10 WARNING[11122]: chan_iax2.c:5546 socket_read: Call rejected by XXX.XXX.XXX.XXX: No authority found Feb 16 15:01:10 NOTICE[11122]: chan_iax2.c:1375 iax2_destroy: Avoiding IAX destroy deadlock -- Hungup 'IAX2/user/1' Even I have entry in iax.conf for this user as a friend, and * server of this user is already

On 02/06/2012 10:02 PM, Preston Briggs wrote: > On Mon, Feb 6, 2012 at 12:13 PM, Sebastian Pop <spop at codeaurora.org > <mailto:spop at codeaurora.org>> wrote: >> [many things, but I'm only going to focus on one of them] Would >> you consider using Polly http://polly.grosser.es to avoid writing >> this code? > > My impression is that Polly (and

On Mon, Feb 6, 2012 at 12:13 PM, Sebastian Pop <spop at codeaurora.org> wrote: > [many things, but I'm only going to focus on one of them] > Would you consider using Polly http://polly.grosser.es to avoid > writing this code? My impression is that Polly (and polyhedral analysis generally) doesn't do want I want. But I'm happy to talk about it 'cause I might be

Hi, I gave a talk at last month's DCLUG[0] meeting on icecast and how we used it at LAC2005[1]. I was trying to stream the talk live while also trying to give the talk and host the meeting. I had the streaming working fine, but then hosed my laptop trying to get the video output to cooperate with the projector. I guess that should teach me to not try to stream and present using the same

On Sat, Feb 4, 2012 at 2:27 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On Fri, 2012-02-03 at 20:59 -0800, Preston Briggs wrote: >> so are building a dependence graph for a complete function.  Of >> course, such a thing is useful for vectorization and all sorts of >> other dependence-based loop transforms. >> >> I'm looking at the problem in two parts:

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

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

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"

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.

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

# RFC: Atomic LL/SC loops in LLVM revisited ## Summary This proposal gives a brief overview of the challenges of lowering to LL/SC loops and details the approach I am taking for RISC-V. Beyond getting feedback on that work, my intention is to find consensus on moving other backends towards a similar approach and sharing common code where feasible. Scroll down to 'Questions' for a summary

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:

On Sun, Jul 31, 2011 at 12:49 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > I noticed the patch was already merged into the current LLVM language > reference manual with new memory instructions, fence, cmpxchg and > atomicrmw. Will the instructions be available in LLVM 3.0? Hopefully, yes; the implementation is in progress. -Eli

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

Hi All, The wiki seems to be struggling this evening. Anyone else seeing this? Michael -- Michael Graves mgraves@pixelpower.com Sr. Product Specialist www.pixelpower.com Pixel Power Inc. mgraves@mstvp.com o713-861-4005 o800-905-6412 c713-201-1262

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

I finally got around to adding these. The patch is posted in a pull request on my copy of llvm.git: https://github.com/jrk/llvm/pull/3 and a simple test with OCaml is here: https://gist.github.com/3948460 Feedback welcome. On Sep 14, 2012, at 7:53 PM, Jonathan Ragan-Kelley <jrk at csail.mit.edu> wrote: > Forgive me if I'm missing something obvious, but it seems that a >

Problem LLVM's memory model for NonAtomic accesses is generally fairly weak, but explicitly disallows inserting stores that didn't occur in the original program.  This is required for any potentially shared location, but is overkill for any memory location which is provably only accessed by a single thread. My particular motivating example is a single thread private field in our