[M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack?

Tony Hosking hosking at cs.purdue.edu
Fri Feb 12 19:35:27 CET 2010


Let's be explicit here.  You want compare_exchange to take an explicit Var?  For which argument?  The memory location being manipulated or the expected value?

compare_exchange (t: MType;  u: ZType;  r: IType;
                  success, failure: MemoryOrder);
(* tmp := Mem[s2.A].t;
   IF (tmp = Mem[s1.A].t)
   THEN Mem [s2.A].t := s0.u; s2.r := 1; pop(2);
   ELSE Mem [s1.A].t := tmp;  s2.r := 0; pop(2);
   END;
   This is permitted to fail spuriously, leaving Mem [s1.A] unchanged.
*)

So, you want s1 to be a Var or s2?


On 12 Feb 2010, at 12:42, Jay K wrote:

> It is easier to generate more efficient code if the variable is passed as a parameter to cg.compare_exchange instead of on the stack.
> We can defer register allocation until we know we must use eax, instead of allocating it "wherever" and then moving it to eax once we know that is where it is needed, as it always will be.
> We can also generate more efficient code for fetch_op if passed function parameters since we don't need to get the address in a register.
>  
> Again, if m3back were multi pass or somehow smarter, it'd be moot.
> I'll be looking into make it one or both of these maybe sometime soon.
>  
>  - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 12 Feb 2010 09:49:14 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack?
> 
> Here's what Boehm produces in his libatomic package.  Don't know if it helps or answers your question.
> 
> The C source:
> 
> int Atomic__CompareSwap_ordered (volatile AO_t *addr, AO_t *old, AO_t new)
> { return AO_compare_and_swap_full(addr, *old, new); }
> 
> generates:
> 
> .globl _Atomic__CompareSwap_ordered
> _Atomic__CompareSwap_ordered:
> LFB526:
> pushq %rbp
> LCFI42:
> movq %rsp, %rbp
> LCFI43:
> movq (%rsi), %rax
> lock; cmpxchgq %rdx, (%rdi); setz %al
> movsbl %al,%eax
> leave
> ret
> LFE526:
> .align 4,0x90
> 
> 
> 
> On 12 Feb 2010, at 04:17, Jay K wrote:
> 
> Tony, currently I have atomic.compare_and_exchange generating e.g.:
>  
>  
>  load_address      gv.2[_MM_Main] 56
>  0000018E: 8D3538000000        LEA ESI gv.2[_MM_Main]+56
>  load_address      gv.2[_MM_Main] 152
>  00000194: 8D3D98000000        LEA EDI gv.2[_MM_Main]+152
>  load              gv.2[_MM_Main] 156 Int.32 Int.32
>  compare_exchange   Int.32 Int.32 Int.32
>  0000019A: 8BC7                MOV EAX EDI
>  0000019C: 8B1D9C000000        MOV EBX gv.2[_MM_Main]+156
>  declare_temp      4 4 Addr F tv.35[T$35] -4
>  000001A2: 8975FC              MOV tv.35[T$35] ESI
>  000001A5: F00FB15DFC          LOCK CMPXCHG  tv.35[T$35]:Addr EBX
>  
> 
> This might not be correct, but it is close.
>  
> 
> Now, the thing is, the eax register is special to lock cmpxchg.
>   It always holds the comparison value.
> 
> The point is, if cg.compare_exchange took its parameters as
> parameters instead of on the stack, it could chose the
> right register right away, instead of as above where it
> choses the wrong one and then must mov it.
>  
> Easy to change it like that?
>  
> 
> I realize this is an m3back deficiency.
> It does the register allocation too early.
> 
>  - Jay
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100212/e6dc5af8/attachment-0002.html>


More information about the M3devel mailing list