[LLVMdev] ASM output with JIT / codegen barriers

[Owen Anderson]

On Jan 3, 2010, at 10:10 PM, James Y Knight 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. 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 different architectures  
> have different possibilities, so I'm not asking for this...).

Why do you want to do this?  As far as I'm aware, there's no guarantee that a memory-memory SUB will be observed atomically across all processors.  Remember that most processors are going to be breaking X86 instructions up into micro-ops, which might get reordered/interleaved in any number of different ways.

> All I really would like is to be able to specify the exact instruction  
> sequence to emit there. I'd hoped that inline asm would be the way to  
> do so, but LLVM doesn't appear to support asm output when using the  
> JIT compiler. Is there any hope for inline asm being supported with  
> the JIT anytime soon? Or is there an alternative suggested way of  
> doing this? I'm using llvm.atomic.load.sub.i64.p0i64 for the moment,  
> but that's both more expensive than I need as it has an unnecessary  
> LOCK prefix, and is also theoretically incorrect. While it generates  
> correct code currently on x86-64, LLVM doesn't actually *guarantee*  
> that it generates a single instruction, that's just "luck".

It's not luck.  That's exactly what the atomic intrinsics guarantee: that no other processor can observe an intermediate state of the operation.  What they don't guarantee per the LangRef is sequential consistency.  If you care about that, you need to use explicit fencing.

--Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2620 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100104/3f64e2b4/attachment.bin>