search for: pseudo_atomic

...gainst signal handlers...they in fact just do more than I need, not less. I'm not sure why I thought they were both more and less than I needed before, and sorry if it confused you about what I'm trying to accomplish. Here's a concrete example, in hopes it will clarify matters: @pseudo_atomic = thread_local global i64 0 declare i64* @alloc(i64) declare void @do_pending_interrupt() declare i64 @llvm.atomic.load.sub.i64.p0i64(i64* nocapture, i64) nounwind declare void @llvm.memory.barrier(i1, i1, i1, i1, i1) define i64* @foo() { ;; Note that we're in an allocation section sto...

Responding to the original email... On Sun, Jan 3, 2010 at 10:10 PM, James Y Knight <foom at fuhm.net> wrote: > In working on an LLVM backend for SBCL (a lisp compiler), there are > certain sequences of code that must be atomic with regards to async > signals. Can you define exactly what 'atomic with regards to async signals' this entails? Your descriptions led me to think

In working on an LLVM backend for SBCL (a lisp compiler), there are certain sequences of code that must be atomic with regards to async signals. So, for example, on x86, a single SUB on a memory location should be used, not a load/sub/store sequence. LLVM's IR doesn't currently have any way to express this kind of constraint (...and really, that's essentially impossible since

...ads of mutually exclusive execution or some such. I'm not familiar with what synchronization occurs as part of the interrupt process, but I'd verify it before making too many assumptions. > This sequence that SBCL does today with its internal codegen is basically > like: > MOV <pseudo_atomic>, 1 > [[do allocation, fill in object, etc]] > XOR <pseudo_atomic>, 1 > JEQ continue > <<call do_pending_interrupt>> > continue: > ... > > The important things here are: > 1) Stores cannot be migrated from within the MOV/XOR instructions to outside &g...

...[atomics.fences] > I'm not familiar with what synchronization occurs as > part of the interrupt process, but I'd verify it before making too > many assumptions. > >> This sequence that SBCL does today with its internal codegen is basically >> like: >> MOV <pseudo_atomic>, 1 >> [[do allocation, fill in object, etc]] >> XOR <pseudo_atomic>, 1 >> JEQ continue >> <<call do_pending_interrupt>> >> continue: >> ... >> >> The important things here are: >> 1) Stores cannot be migrated from within th...

...I'm not familiar with what synchronization occurs as >> part of the interrupt process, but I'd verify it before making too >> many assumptions. >> >>> This sequence that SBCL does today with its internal codegen is basically >>> like: >>> MOV <pseudo_atomic>, 1 >>> [[do allocation, fill in object, etc]] >>> XOR <pseudo_atomic>, 1 >>> JEQ continue >>> <<call do_pending_interrupt>> >>> continue: >>> ... >>> >>> The important things here are: >>> 1) Stor...