[LLVMdev] Proposal for atomic and synchronization instructions

[John Criswell]

Chandler Carruth wrote:
> Hello,
>
> After a fair amount of research and work, I have put together a
> concrete proposal for LLVM representations of atomic operations and
> synchronization constructs. These aim to provide the minimal
> functionality in the IR for representing the hardware constructs that
> threading libraries and parallel programming rely on.
>
> http://chandlerc.net/llvm_atomics.html
>
> While I am no expert on the various architectures, I've done my best
> at providing base-line implementations for each instruction. I am sure
> these will need tweaking and fixing, but should provide a very good
> starting point for the targets.
>
> Comments are more than welcome, especially suggestions for
> improvement. I hope this provides a sound background and a good
> starting place for bringing these features to LLVM. Many thanks also
> go to Reid who has helped tremendously with putting this together, and
> several of the people at Aerospace who helped in the research phase.
>   
This looks good; this is basically what we came up with for the SVA-OS work.

Some comments:

1) You may want to consider adding atomic load-<bitwise operation>-store
instructions in addition to load-<add/subtract> instructions.  The Linux
kernel uses these for atomic bit setting/clearing, and on many systems
they can be implemented more efficiently using special assembly
instructions.  That said, I have never run experiments to verify that
such instructions are critical to kernel performance.

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.

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?

4) For consistency, you may need to specify that the LLVM volatile
keyword can be added to the atomic operations to prevent optimizations
from modifying or removing them.   I'm not aware of any optimization
that works on atomic ops in practice, but I don't see why they couldn't
be written.

5) With the addition of membar instructions, it may be time to re-think
what the LLVM volatile keyword means.  Currently, volatile prevents
removing, modifying, or reordering of a load or store.  However, membar
also prevents reordering.  Perhaps it would be useful to redefine
volatile to mean that a load/store cannot be removed or modified but can
be reordered, and membar alone prevents reordering.

-- John T.
> -Chandler Carruth
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>