search for: obj_len

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

...ier(i1 0, i1 0, i1 0, i1 1, i1 0) ;; Call might actually be inlined, so cannot depend upon unknown call causing correct codegen effects. %obj = call i64* @alloc(i64 32) %obj_header = getelementptr i64* %obj, i64 0 store i64 5, i64* %obj_header ;; store obj type (5) in header word %obj_len = getelementptr i64* %obj, i64 1 store i64 2, i64* %obj_len ;; store obj length (2) in length slot ...etc... ;; Check if we were interrupted: %res = call i64 @llvm.atomic.load.sub.i64.p0i64(i64* @pseudo_atomic, i64 1) %was_interrupted = icmp eq i64 %res, 1 br i1 %was_interrupte...

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