similar to: [LLVMdev] Why can't atomic loads and stores handle floats?

David provided one good answer. I'll give another. The current design pushes complexity into the language frontend for - as far as I know - no good reason. I can say from recent experience that the corner cases around atomics are both surprising and result in odd looking hacks in the frontend. To say this differently, why should marking loads and stores atomic required me to rewrite

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

You folks are the greatest. Rolled out my first Samba "member server" today. Read the stuff from SWAT, and it worked the first time on RH7.3, after it failed on RH8 You folks are the best, we're struggling to stay afloat and M$ squeezes us for more. (RH is pushing me to Debian by the day!!!) There will be a lot more Samba in the farm soon. My deepest grattitude. Respectully,

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

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

Hi, I am currently studying the possibility to make the transition from gcc 4.2 to llvm-gcc 4.2 for the projects I am working on. These projects are huge projects, most of the source code is written in C++ but we have objc, c and assembly code. We are targeting MacOSX 10.5 and MacOSX 10.6. Our build system is currently running on MacOSX 10.5 and uses Xcode 3.1.4 with gcc 4.2. It is used to

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"

> 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

Hi everyone, The OpenMP standards committee has begun work to formalize their memory model, and define its relationship to the C/C++ memory models. A questionnaire has been put together (pasted below), and I'd like everyone's help in composing detailed answers to inform their decision-making process. While our OpenMP support is still in active development, many of these questions apply

> Longer term, I hope to improve the fence elimination of the ARM backend with > a kind of PRE algorithm. Both of these improvements to the ARM backend > should be fairly straightforward to port to the POWER architecture later, > and I hope to also do that. > > Any reason these couldn't be done at the IR level? I definitely agree here. At the time, it was a plausible idea

Dear Daniel Berlin, I just tried MemorySSA analysis and get the next IR. However, I feel confused by the result. Specifically, why instruction *%3* relates to a *MemoryDef*. According to my understanding, I think *%3* should be related to a *MemoryUse*, right? ; Function Attrs: uwtable define void @_Z2f1v() #3 personality i32 (...)* @__gxx_personality_v0 { entry: ; 1 = MemoryDef(liveOnEntry)

Hi, TL;DR: should we add a new memory ordering to fences? ``fence seq_cst`` is currently use to represent two things: - GCC-style builtin ``__sync_synchronize()`` [0][1]. - C11/C++11's sequentially-consistent thread fence ``std::atomic_thread_fence(std::memory_order_seq_cst)`` [2]. As far as I understand: - The former orders all memory and emits an actual fence instruction. - The

struct { volatile int flag; int value; } s; int get_value_when_ready() { while (s.flag) ; __sync_synchronize(); return s.value; } This is "valid" legacy code on some processors, yet it's not valid to replace __sync_synchronize with an atomic_thread_fence because, in theory, LLVM could hoist the load of s.value. In practice it currently doesn't, but it may in the

2013/7/31 JF Bastien <jfb at google.com>: > Hi, > > TL;DR: should we add a new memory ordering to fences? > > > ``fence seq_cst`` is currently use to represent two things: > - GCC-style builtin ``__sync_synchronize()`` [0][1]. > - C11/C++11's sequentially-consistent thread fence > ``std::atomic_thread_fence(std::memory_order_seq_cst)`` [2]. > > As far

> From my reading of Atomics.rst, it would be sound to reorder (It does not > say much about load-linked, so I am treating it as a normal load here) > >> store seq_cst >> fence release >> load-linked monotonic > > into > >> load-linked monotonic >> store seq_cst >> fence release > Which would make an execution ending in %old_x = %old_y = 0

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

Ok, it's taken me a while, but here's what seems to be the problem. In OSX I see a lock on the file. If that lock is ON, it disappears. But what is that lock and where did it come from.... Is it like a read only lock? On Thu, Mar 30, 2017 at 11:04 AM Curtis Vaughan <cavaughan at gmail.com> wrote: > Ok, here's what seems to be going on. When a JPG is put into a share it >

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 which meet the other requirements. (i.e. power-of-two multiple of 8 bits, and aligned) This will enable a couple of follow on changes: 1) Teaching the vectorizer how to vectorize unordered atomic loads and stores 2)

On 2009-10-29 23:55, Jeffrey Yasskin wrote: > On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray > <nicolas.geoffray at lip6.fr> wrote: > >> Hi Jeffrey, >> >> Jeffrey Yasskin wrote: >> >>> Cool, I'll start implementing it. >>> >>> >> Great! Thanks. >> >> Just to clarify things: on my end, it

On Sat, Dec 12, 2015 at 1:24 AM, Philip Reames <listmail at philipreames.com> wrote: > Patch posted for review: http://reviews.llvm.org/D15471 Looking at the patch, I think we should do FP only for now as vectors have extra complexities which IMO warrant more discussion. -------------- next part -------------- An HTML attachment was scrubbed... URL: