Displaying 3 results from an estimated 3 matches for "was_interrupted".
2010 Jan 04
0
[LLVMdev] ASM output with JIT / codegen barriers
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
2010 Jan 04
2
[LLVMdev] ASM output with JIT / codegen barriers
...* %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_interrupted, label %do-interruption, label %continue
continue:
ret i64* %obj
do-interruption:
call void @do_pending_interrupt()
br label %continue
}
A signal handler will check the thread-local @pseudo_atomic variable:
if it was already set it will...
2010 Jan 04
4
[LLVMdev] ASM output with JIT / codegen barriers
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