search for: jeq

...td another RegisterClass (taken from the Mips backend): def MSA128W: RegisterClass<"BPF", [v2i64, v2f64], 128, (sequence "W%u", 0, 31)>; in order to support vector for example, ADD operations, I get the following error when building llc: JEQ_ri: (BPFbrcc i64:i64:$dst, (imm:i64)<<P:Predicate_i64immSExt32>>:$imm, (imm:{i64:v4i32})<<P:Predicate_BPF_CC_EQ>>, (bb:Other):$BrDst) Included from ~/LLVM/llvm38Nov2016/llvm/lib/Target/BPF/BPF.td:14: ~/LLVM/llvm38Nov2016/llvm/lib/Target/BPF/BPFInstrInfo.td:131:1: er...

...am sure of. Unfortunately llvm has this knack for ordering my one most crucial part of code exactly the opposite I want to, it does: (x86_64) cmpq %r15, (%rax,%rdx) jne LBB0_3 Ltmp18: leaq 8(%rax,%rdx), %rcx jmp LBB0_4 LBB0_3: addq $8, %rcx LBB0_4: when I want, cmpq %r15, (%rax,%rdx) jeq LBB0_3 addq $8, %rcx jmp LBB0_4 LBB0_3: leaq 8(%rax,%rdx), %rcx LBB0_4: since that saves me executing a jump 99.9% of the time. Is there anything I can do ? Ciao Nat!

...ps backend): >> def MSA128W: RegisterClass<"BPF", [v2i64, v2f64], 128, >> (sequence "W%u", 0, 31)>; >> in order to support vector for example, ADD operations, I get the following error when >> building llc: >> JEQ_ri: (BPFbrcc i64:i64:$dst, (imm:i64)<<P:Predicate_i64immSExt32>>:$imm, >> (imm:{i64:v4i32})<<P:Predicate_BPF_CC_EQ>>, (bb:Other):$BrDst) >> Included from ~/LLVM/llvm38Nov2016/llvm/lib/Target/BPF/BPF.td:14: >> ~/LLVM/llvm38Nov2016/llvm/lib/Target/BPF...

...of the pseudo-atomic section. This is because it may get confused by the proto-object being built up in this code. 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. 2) There's no way an interruption can be missed: the XOR is atomic with regards to signals executing...

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

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

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

...king 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. >> >> B...

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