[LLVMdev] Proposal for a new LLVM concurrency memory model

[Chandler Carruth]

On Mon, Apr 26, 2010 at 11:46 AM, David Greene <dag at cray.com> wrote:

> On Monday 26 April 2010 10:19:06 Renato Golin wrote:
> > On 26 April 2010 15:59, Jeffrey Yasskin <jyasskin at google.com> wrote:
> > > To be clear, Chandler wasn't suggesting any change to the existing
> > > load and store instructions. Instead, we were wondering if people like
> > > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe
> > > atomic_exchange and atomic_add instructions.
> >
> > I see, in that case, I don't have any strong opinion. Maybe new
> > instructions would be simpler and cleaner...
> >
> > I quite like the idea of having more expressive atomic operators, as
> > it'll be easier to map high-level synchronization concepts to IR.
>
> I don't have a strong preference, but I am curious why all the atomics
> are integer-only.  I would like to see 32- and 64-bit float supported as
> well, at minimum.
>

I have no real problem with making the types of all of these analogous to
the types supported by icmp, and providing floating point atomics as well. A
couple of observations:

Allowing direct use of pointers would be convenient I suspect -- pointers
are very common operands to atomic operations, and it seems annoying to have
to convert them to ints.

We can allow the IR to represent vectors, but unless hardware supports it, I
think lowering these by decomposing them is more than LLVM should try to do.
Because of that, I'm not sure we should support vectors as elsewhere they
degrade gracefully.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100426/6b66ee75/attachment.html>