search for: atomic_load

...mpilation stub should spin waiting on a lock (implemented using atomics), and the compilation callback should execute while holding the lock just before patching the callsite, so it would look like this in pseudocode: callsite_patch_state = 0;// for each callsite one byte of memory callsite: if (atomic_load(&callsite_patch_state) == 2) { //fast-path: already compiled and patched patchsite: jmp <nop nop nop nop nop nop nop nop> // will be patched } // not yet patched, it may already be compiling if (atomic_test_and_set(&callsite_patch_state, 0, 1) == 0) { // not yet co...

...; option I mentioned in the bug. Would you add it to the bug so we don't lose it? I think we can put the entire "not yet patched" branch inside the compilation callback to minimize the code size impact: callsite_patch_state = 0;// for each callsite one byte of memory callsite: if (atomic_load(&callsite_patch_state) != 2) { call CompilationCallback // Doesn't return until the patchsite is patched. } //fast- and slow-path: already compiled and patched patchsite: call <nop nop nop nop nop nop nop nop> // will be patched > callsite_patch_state = 0;// for each call...

On 26 April 2010 15:59, Jeffrey Yasskin <jyasskin at google.com> wrote: > To be clear, Chandler wasn't suggesting any change to the existing > load and store instructions. Instead, we were wondering if people like > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > atomic_exchange and atomic_add instructions. I see, in that case, I don't have any strong opinion. Maybe new instructions would be simpler and cleaner... I quite like the idea of having more expressive atomic operators, as it'll be easier to m...

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

...; If you add it to the instructions, their syntax will be more complex > than they are today, and reading them could prove a challenge. To be clear, Chandler wasn't suggesting any change to the existing load and store instructions. Instead, we were wondering if people like the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe atomic_exchange and atomic_add instructions. > IMHO, we should keep it simple. I agree that multi-task is ubiquitous > nowadays but the detailed implementation might vary considerably from > language to language and making it explicit only helps, a...

...:19:06 Renato Golin wrote: > On 26 April 2010 15:59, Jeffrey Yasskin <jyasskin at google.com> wrote: > > To be clear, Chandler wasn't suggesting any change to the existing > > load and store instructions. Instead, we were wondering if people like > > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > > atomic_exchange and atomic_add instructions. > > I see, in that case, I don't have any strong opinion. Maybe new > instructions would be simpler and cleaner... > > I quite like the idea of having more expressive atomic operators,...

...d no pattern and the latter, when mayStore was implied in the pattern. > > If only TableGen wouldn't warn about non-conflicting attributes at least… That warning has been removed now, and you should be able to clean up your classes. I also filed PR13693 for you. It's a bug to lower atomic_load to an instruction without mayStore - atomic loads can't be reordered. /jakob

On 26 April 2010 10:49, Chandler Carruth <chandlerc at google.com> wrote: > Certainly for languages such as Java, they will make up a surprisingly large > chunk of the loads and stores, and instructions have much mor flexibility in > terms of syntax. On the flip side, it's a lot of plumbing IIRC, and we'd > really need to stick to the very minimal set of operations,

Looking through the documentation, I discovered that atomic loads and stores are only supported for integer types. Can anyone provide some background on this? Why is this true? Currently, given code: std::atomic<float> aFloat; void foo() { float f = atomic_load(&aFloat); .. } Clang generates code like:|| %"struct.std::atomic.2" = type { float } @aFloat = global %"struct.std::atomic.2" zeroinitializer, align 4 define void @foo() { %1 = load atomic i32* bitcast (%"struct.std::atomic.2"* @aFloat to i32*) seq_cst, al...

On 08/21/12 16:49, Jim Grosbach wrote: > > I like that. Possibly with the addition that we can filter by a specific property. -Winfer=neverHasSideEffects, e.g., would only show when that specific property is inferred. > > Beyond that, I don't see an alternative to an audit of the instructions that get flagged by such a warning. :( This proposal would certainly make my life easier

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 doesn't really matter what is the > default behavior, as long as vmkit can continue to have the existing >

...d you add it to the bug so we don't lose it? > > I think we can put the entire "not yet patched" branch inside the > compilation callback to minimize the code size impact: > > callsite_patch_state = 0;// for each callsite one byte of memory > > callsite: > if (atomic_load(&callsite_patch_state) != 2) { > call CompilationCallback // Doesn't return until the patchsite is patched. > } > //fast- and slow-path: already compiled and patched > patchsite: > call <nop nop nop nop nop nop nop nop> // will be patched > > Yes, tha...

...et can only have one core, it is sufficient to: - Save the status register - Disable interrupts - Do the nonatomic LOAD/STORE/SWAP/ADD - Restore the status register I’d really like to be able to do this at the IR level. What I want to do is write a custom lowering hook to convert ISD::ATOMIC_LOAD into a standard ISD::LOAD with the save/restore/interrupt nodes glued to it. Here’s what I have so far: // Store `SREG` auto Save = DAG.getCopyFromReg(DAG.getEntryNode(), DL, AVR::SREG, MVT::i8); // Disable interrupts (`clr` is equivalent to `bclr 7`). auto ClearInterrupts = DAG.getNode(...

...ath overhead is only a virtually > 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++) > shar...

Hi, I've tagged 3.8.1-rc1, testers can begin testing. -Tom

Hi Jeffrey, Jeffrey Yasskin wrote: > Cool, I'll start implementing it. > Great! Thanks. Just to clarify things: on my end, it doesn't really matter what is the default behavior, as long as vmkit can continue to have the existing behavior of lazy compilation. With Chris' solution, I was wondering how you would implement the getPointerToFunction{Eager, Lazy} functions when

...ss.cpp libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_init.pass.cpp libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_is_lock_free.pass.cpp libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_load.pass.cpp libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_load_explicit.pass.cpp libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_store.pass.cpp libc++ :: std/atomics/atomics.types.operations/atomics.types.operations...

...wrote: > > On 26 April 2010 15:59, Jeffrey Yasskin <jyasskin at google.com> wrote: > > > To be clear, Chandler wasn't suggesting any change to the existing > > > load and store instructions. Instead, we were wondering if people like > > > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > > > atomic_exchange and atomic_add instructions. > > > > I see, in that case, I don't have any strong opinion. Maybe new > > instructions would be simpler and cleaner... > > > > I quite like the idea of having mor...

...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 = computesh...

...entation, I discovered that atomic loads and >> stores are only supported for integer types. Can anyone provide some >> background on this? Why is this true? >> >> Currently, given code: >> std::atomic<float> aFloat; >> void foo() { >> float f = atomic_load(&aFloat); >> .. >> } >> >> Clang generates code like:|| >> %"struct.std::atomic.2" = type { float } >> @aFloat = global %"struct.std::atomic.2" zeroinitializer, align 4 >> >> define void @foo() { >> %1 = load atomic i...