search for: do_pending_interrupt

...;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 store i64 1, i64* @pseudo_atomic ;; Barrier only to ensure instruction ordering, not nee...

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

...s, 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 > by the codegen. Basically, this is merely the problem that x86 places a stricter requirement on memory ordering than LLVM. Where x86 requi...

...g 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 >> by the codegen. > > Basically, this is merely the problem that x86 places a stricter > requirement on memo...

...;> >>> 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 >>> by the codegen. >> >> Basically, this is merely the problem that x86 places a s...