search for: atomic_ops

...generally rare. And no, I am not speculating about architectures in general, for that matter. I simply like LL/SC and think it's superior to most other primitives, being a matter of good taste. BTW: It's not my proposal. I merely work with Chandler. >>> Please have a real look at atomic_ops first. It does have a library >>> part to it -- but that's just for a nonblocking stack. >> It's a lot like Apple's (and gcc's) work to reconcile the Intel and PPC >> vector intrinsics. Nice work but an unnecessary dependency, in my >> personal and not so...

...No. So what are you trying to say, why is the paragraph in the proposal? You seem to be speculating about architectures in general in one paragraph. IMHO, I wouldn't try that, because I would have to be either imprecise or don't state anything new. > > Please have a real look at atomic_ops first. It does have a library > > part to it -- but that's just for a nonblocking stack. > > It's a lot like Apple's (and gcc's) work to reconcile the Intel and PPC > vector intrinsics. Nice work but an unnecessary dependency, in my > personal and not so humble opi...

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

...on't have to be used that way. I suspect that current work on software transactional memory is LL/SC-like on memory regions -- if you look at the paper, there is a chunk of code in the examples that rolls back or restarts a computation if the SC operation fails. > Please have a real look at atomic_ops first. It does have a library part to > it -- but that's just for a nonblocking stack. It's a lot like Apple's (and gcc's) work to reconcile the Intel and PPC vector intrinsics. Nice work but an unnecessary dependency, in my personal and not so humble opinion. > Second, I g...

...cked the Load/Store model for > barriers and not some other kind (e.g., acquire/release/...)? Chandler looked at what the various current LLVM architectures and summarized what he found. What he found are the memory barriers that the various processors support. > Did you have a look at the atomic_ops project? > http://www.hpl.hp.com/research/linux/atomic_ops/ > It already has implementations for several architectures and several > compilers. It uses a different consistency model (different set of > constraints for operations) and groups necessary memory barriers with > instruc...

...use, but I think some architectures such as Itanium offer different membars with different costs. So if you pick the wrong model and have to use stronger membars (mfence Itanium) to implement your model, than you pay for that by decreased performance. > > > Did you have a look at the atomic_ops project? > > http://www.hpl.hp.com/research/linux/atomic_ops/ > > It already has implementations for several architectures and several > > compilers. It uses a different consistency model (different set of > > constraints for operations) and groups necessary memory barriers...

On Tue, 10 Jul 2007, Scott Michel wrote: >> The idea is to review the atomic_ops model, and if it makes sense, just >> reuse it. (e.g., atomic_ops seems to have (basic?) support for Alpha). > > atomic_ops may have interesting ideas on how Chandler might proceed and > implement, but using its code is very unlikely. I think that Torvald's point here is that th...

...re-and-set) to return the previous value (I think some architectures don't), but just return a boolean value (success/failure). What are the reasons because of which you picked the Load/Store model for barriers and not some other kind (e.g., acquire/release/...)? Did you have a look at the atomic_ops project? http://www.hpl.hp.com/research/linux/atomic_ops/ It already has implementations for several architectures and several compilers. It uses a different consistency model (different set of constraints for operations) and groups necessary memory barriers with instructions (helpful on some ar...

Hi, You might want to use this: http://www.hpl.hp.com/research/linux/atomic_ops/ Zoltan On Sat, May 16, 2009 at 11:11 PM, Owen Anderson <resistor at mac.com> wrote: > Some of you may have noticed that I addedd include/llvm/System/Atomics.h to > the repository briefly, which will be used for adding support for threading > in LLVM....

Surprisingly enough, libatomic_ops doesn't define just a hardware memory fence call as far as I can tell. --Owen On May 16, 2009, at 3:00 PM, Zoltan Varga wrote: > Hi, > > You might want to use this: > > http://www.hpl.hp.com/research/linux/atomic_ops/ > > Zoltan > >...

...mand for building memory semantics into the atomic instructions, "aquire" and "release" flags could be used, and implementations appropriately handle them. This doesn't seem to anull the need for non-operation-based memory barriers. > > > Did you have a look at the atomic_ops project? > > > http://www.hpl.hp.com/research/linux/atomic_ops/ > > > It already has implementations for several architectures and several > > > compilers. It uses a different consistency model (different set of > > > constraints for operations) and groups necess...

Some of you may have noticed that I addedd include/llvm/System/ Atomics.h to the repository briefly, which will be used for adding support for threading in LLVM. I have tried to provided appropriate implementations of the atomic ops (currently memory fence and CAS) for platforms we care about, but my knowledge of these, and my ability to test them, is limited. So, please, if you run on

...y fence, and a hardware+compiler fence, but no hardware-only fence, I believe for this reason. See <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf>, section 29.8. On Sat, May 16, 2009 at 7:33 PM, Owen Anderson <resistor at mac.com> wrote: > Surprisingly enough, libatomic_ops doesn't define just a hardware memory > fence call as far as I can tell. > --Owen > On May 16, 2009, at 3:00 PM, Zoltan Varga wrote: > > Hi, > >   You might want to use this: > > http://www.hpl.hp.com/research/linux/atomic_ops/ > >                              Z...

...e from the draft. > > > an operation based constraint cannot guard other operations > > I think constraints associated with a particular instruction usually apply > to this instruction and previous/subsequent instructions, so this wouldn't > be true. This is the case in the atomic_ops model, and also on ia64 I > think. "guard other operations" means guarding operations other than the atomic intrinsic functions. Specifically, loads from and stores to shared memory are perfectly legal, and inherently atomic. However, they might need memory synchronization routines. T...

...ler fence, > but no hardware-only fence, I believe for this reason. See > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf>, > section 29.8. > > On Sat, May 16, 2009 at 7:33 PM, Owen Anderson <resistor at mac.com> wrote: >> Surprisingly enough, libatomic_ops doesn't define just a hardware memory >> fence call as far as I can tell. >> --Owen >> On May 16, 2009, at 3:00 PM, Zoltan Varga wrote: >> >> Hi, >> >> You might want to use this: >> >> http://www.hpl.hp.com/research/linux/atomic_ops/ >...

Hello, After a fair amount of research and work, I have put together a concrete proposal for LLVM representations of atomic operations and synchronization constructs. These aim to provide the minimal functionality in the IR for representing the hardware constructs that threading libraries and parallel programming rely on. http://chandlerc.net/llvm_atomics.html While I am no expert on the

...e some comments, quotes are from the draft. > an operation based constraint cannot guard other operations I think constraints associated with a particular instruction usually apply to this instruction and previous/subsequent instructions, so this wouldn't be true. This is the case in the atomic_ops model, and also on ia64 I think. > The single instruction constraints can, at their most flexible, constrain > any set of possible pairings of loads from memory and stores to memory I'm not sure about this, but can we get issues due to "special" kinds of data transfers (su...

Hello, This is the second major revision of the atomic proposal for LLVM. I will try and give a brief overview of the motivating changes, but a greater portion of the text has changed, along with some changes to the proposed additions. http://chandlerc.net/llvm_atomics.html - The proposal has been rewritten to better delineate the goals and purposes of LLVM, and these additions to LLVM. The why

That is good to hear. The lack of Alpha was purely a lack of time/knowledge of the architecture on my part, hopefully I can start learning some more about how it functions. If you send me either a pointer to appropriate documentation I would be happy to add appropriate information to the page. If you can provide implementations, it would save time, but I don't mind doing a fair portion of the

...ecode support Mikhail Golubev (1): xf86drm: Check non-absolute path only for virtio based devices Nicholas Bishop (2): intel: properly escape sed pattern for tests libdrm: intel: add DRM_RDWR flag in drm_intel_bo_gem_export_to_prime Peter Seiderer (1): tests/amdgpu: needs atomic_ops Scott Anderson (1): libdrm: Handle usb_interface devices for usb parsing git tag: libdrm-2.4.102 https://dri.freedesktop.org/libdrm/libdrm-2.4.102.tar.xz SHA256: 8bcbf9336c28e393d76c1f16d7e79e394a7fce8a2e929d52d3ad7ad8525ba05b libdrm-2.4.102.tar.xz SHA512: 386afd228efd809fe32776a6ff5d9dd9...