search for: memory_order_consum

Hello! A proposal (quaintly identified as P0190R0) for a new memory_order_consume definition may be found here: http://www2.rdrop.com/users/paulmck/submission/consume.2016.02.10b.pdf As requested at the October C++ Standards Committee meeting, this is a follow-on to P0098R1 that picks one alternative and describes it in detail. This approach focuses on existing practice, wi...

....org; j.alglave at ucl.ac.uk; will.deacon at arm.com; dhowells at redhat.com; Ramana.Radhakrishnan at arm.com; luc.maranget at inria.fr; akpm at linux-foundation.org; Peter.Sewell at cl.cam.ac.uk; torvalds at linux-foundation.org; mingo at kernel.org > Subject: [isocpp-parallel] Proposal for new memory_order_consume definition > > Hello! > > A proposal (quaintly identified as P0190R0) for a new memory_order_consume > definition may be found here: > > http://www2.rdrop.com/users/paulmck/submission/consume.2016.02.10b.pdf > > As requested at the October C++ Standards Committee mee...

...cl.ac.uk; will.deacon at arm.com; > dhowells at redhat.com; Ramana.Radhakrishnan at arm.com; luc.maranget at inria.fr; > akpm at linux-foundation.org; Peter.Sewell at cl.cam.ac.uk; > torvalds at linux-foundation.org; mingo at kernel.org > > Subject: [isocpp-parallel] Proposal for new memory_order_consume > definition > > > > Hello! > > > > A proposal (quaintly identified as P0190R0) for a new > memory_order_consume > > definition may be found here: > > > > http://www2.rdrop.com/users/paulmck/submission/consume.2016.02.10b.pdf > > > > As r...

On Feb 27, 2016 09:06, "Paul E. McKenney" <paulmck at linux.vnet.ibm.com> wrote: > > > But we do already have something very similar with signed integer > overflow. If the compiler can see a way to generate faster code that > does not handle the overflow case, then the semantics suddenly change > from twos-complement arithmetic to something very strange. The

On 2016.02.27 at 15:10 -0800, Paul E. McKenney via llvm-dev wrote: > On Sat, Feb 27, 2016 at 11:16:51AM -0800, Linus Torvalds wrote: > > On Feb 27, 2016 09:06, "Paul E. McKenney" <paulmck at linux.vnet.ibm.com> > > wrote: > > > > > > > > > But we do already have something very similar with signed integer > > > overflow. If the

...cDeprecated.h:756:17: error: reference to 'memory_order_relaxed' is ambiguous __theAmount, memory_order_relaxed) + __theAmount); ^ .../usr/bin/../include/c++/v1/atomic:548:5: note: candidate found by name lookup is 'std::__1::memory_order::memory_order_relaxed' memory_order_relaxed, memory_order_consume, memory_order_acquire, ^ ../src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_atomic.h:22:3: note: candidate found by name lookup is '__sanitizer::memory_order::memory_order_relaxed' memory_order_relaxed = 1 << 0, ^ The problem is due to the combination of the followin...

Hi, On Sun, 28 Feb 2016, Linus Torvalds wrote: > > So the kernel obviously is already using its own C dialect, that is > > pretty far from standard C. All these options also have a negative > > impact on the performance of the generated code. > > They really don't. They do. > Have you ever seen code that cared about signed integer overflow? > > Yeah,

On 2/28/16, Linus Torvalds <torvalds at linux-foundation.org> wrote: > The fact is, undefined compiler behavior is never a good idea. Not for > serious projects. Actually, undefined behavior is essential for serious projects, but not for the reasons mentioned. If the language has no undefined behavior, then from the compiler's view, there is no such thing as a bad program. All

On Sat, Feb 27, 2016 at 11:16:51AM -0800, Linus Torvalds wrote: > On Feb 27, 2016 09:06, "Paul E. McKenney" <paulmck at linux.vnet.ibm.com> > wrote: > > > > > > But we do already have something very similar with signed integer > > overflow. If the compiler can see a way to generate faster code that > > does not handle the overflow case, then the

Hi, On Sat, 27 Feb 2016, Paul E. McKenney wrote: > But we do already have something very similar with signed integer > overflow. If the compiler can see a way to generate faster code that > does not handle the overflow case, then the semantics suddenly change > from twos-complement arithmetic to something very strange. The standard > does not specify all the ways that the

...n at arm.com; > > dhowells at redhat.com; Ramana.Radhakrishnan at arm.com; luc.maranget at inria.fr; > > akpm at linux-foundation.org; Peter.Sewell at cl.cam.ac.uk; > > torvalds at linux-foundation.org; mingo at kernel.org > > > Subject: [isocpp-parallel] Proposal for new memory_order_consume > > definition > > > > > > Hello! > > > > > > A proposal (quaintly identified as P0190R0) for a new > > memory_order_consume > > > definition may be found here: > > > > > > http://www2.rdrop.com/users/paulmck/submission/con...

...9;memory_order_relaxed' is ambiguous >> __theAmount, memory_order_relaxed) + __theAmount); >> ^ >> .../usr/bin/../include/c++/v1/atomic:548:5: note: candidate found by name >> lookup is 'std::__1::memory_order::memory_order_relaxed' >> memory_order_relaxed, memory_order_consume, memory_order_acquire, >> ^ >> ../src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_atomic.h:22:3: >> note: candidate found by name lookup is >> '__sanitizer::memory_order::memory_order_relaxed' >> memory_order_relaxed = 1 << 0, >> ^...

On Sun, Feb 28, 2016 at 12:27 AM, Markus Trippelsdorf <markus at trippelsdorf.de> wrote: >> > >> > -fno-strict-overflow >> >> -fno-strict-aliasing. > > Do not forget -fno-delete-null-pointer-checks. > > So the kernel obviously is already using its own C dialect, that is > pretty far from standard C. > All these options also have a negative

...s our back (or front if the stack grows up ☻). *What about non-x86 architectures?* Architectures such as ARMv8 support non-temporal instructions and require barriers such as DMB nshld to order loads and DMB nshst to order stores. Even ARM's address-dependency rule (a.k.a. the ill-fated std::memory_order_consume) fails to hold with non-temporals: LDR X0, [X3] LDNP X2, X1, [X0] // X0 may not be loaded when the instruction executes! *Who uses non-temporals anyways?* That's an awfully personal question! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists....

...ally > zero overhead (if implemented properly in the compiler) atomic consume load: > > const int maxshard = 4096; > uint64* shard[maxshard]; > atomic<int> shardmask; > > void inline inccounter(int idx) > { > int shardidx = gettid() & atomic_load(&shardmask, memory_order_consume); > shard[shardidx][idx]++; > } > > int pthread_create(...) > { > if (updateshardcount()) { > shardlock(); > if (updateshardcount()) { > int newcount = computeshardcount(); > for (int i = oldcount; i < newcount; i++) > shard[i] = malloc(ncounter*sizeof(uint64...

...*What about non-x86 architectures?* > > > > Architectures such as ARMv8 support non-temporal instructions and require > barriers such as DMB nshld to order loads and DMB nshst to order stores. > > > > Even ARM's address-dependency rule (a.k.a. the ill-fated > std::memory_order_consume) fails to hold with non-temporals: > > LDR X0, [X3] > > LDNP X2, X1, [X0] // X0 may not be loaded when the instruction executes! > > > > What exactly do you mean by ‘X0 may not be loaded’ in your example here? > If you mean that the LDNP > > could start executing w...

On Tue, Jun 30, 2020 at 09:47:30PM +0200, Marco Elver wrote: > I do wonder, though, if there is some way to make the compiler do > something better for us. Clearly, implementing real > memory_order_consume hasn't worked out until today. But maybe the > compiler could promote dependent loads to acquires if it recognizes it > lost dependencies during optimizations. Just thinking out loud, it > probably still has some weird corner case that will break. ;-) I'd be very hesitant to let...

...> > about dependent loads. What (if any), is the performance impact? I > > guess this also heavily depends on the actual silicon. > > > > I do wonder, though, if there is some way to make the compiler do > > something better for us. Clearly, implementing real > > memory_order_consume hasn't worked out until today. But maybe the > > compiler could promote dependent loads to acquires if it recognizes it > > lost dependencies during optimizations. Just thinking out loud, it > > probably still has some weird corner case that will break. ;-) > > > &gt...

...non-x86 architectures? > > > Architectures such as ARMv8 support non-temporal instructions and > > require barriers such as DMB nshld to order loads and DMB nshst to > > order stores. > > > Even ARM's address-dependency rule (a.k.a. the ill-fated > > std::memory_order_consume ) fails to hold with non-temporals: > > > > LDR X0, [X3] > > > > > > LDNP X2, X1, [X0] // X0 may not be loaded when the instruction > > > executes! > > > > > Who uses non-temporals anyways? > > > That's an awfully personal...

Hi, what's the current status of the memory-ordered operations described in https://docs.google.com/Doc?docid=0AYWBeVVqyP7dZGRiNG1oeHpfMjJkejVnOThkZA&hl=en.&pli=1 i.e. the ones for "load acquire", "store release" etc. for C++0x atomics, not the older ones for the __sync intrinsics? The specification looks good - is it just waiting to be implemented? Al --