[LLVMdev] Proposal for atomic and synchronization instructions

[Christopher Lamb]

On Jul 9, 2007, at 2:26 PM, Chandler Carruth wrote:

> On 7/9/07, John Criswell <criswell at cs.uiuc.edu> wrote:
>> 2) You need a strategy for handling architectures that can't handle
>> atomic operations on certain LLVM data types.  For example, 64 bit
>> machines can operate atomically on 64 bit operands, but some 32 bit
>> machines cannot.  I think you can fix this with spin locking, but you
>> need to be careful on how you do it.  I think in order to do it
>> correctly, you need a separate spinlock variable for each individual
>> instruction that requires a spinlock.
>
> Indeed, which is very dangerous with potential for deadlock, etc.
> After discussing this on IRC, I have adjusted the proposal to reflect
> the idea that the target implementation can reject any instructions
> with operands which they cannot effectively lower to an atomic
> operation. This makes the available types for the instruction
> architecture dependent, but when relying on the atomic architecture
> implementation, this seems part of the package.
>
>> 3) You say that your operations work on all first class LLVM data
>> types.  The LLVM vector type is considered a first class type.   
>> Should
>> LLVM support atomic vector operations?
>
> Thanks for pointing this out! Continuing with the changes above, I
> have changed the proposal to state that these instructions only accept
> integer types. This should provide the needed functionality of these
> operations, while keeping a clear lowering path to the target
> architecture.

This probably isn't needed for the mainstream architectures listed in  
the proposal, but wouldn't it be good to let all of the instructions  
support types based on the specific target rather than just limiting  
them to integer types? If the target supports atomic operations on,  
say vectors, then I'd think that should be allowed.

--
Christopher Lamb



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070709/88b1bc54/attachment.html>