llvm dev - Apr 2010 - [LLVMdev] Proposal for a new LLVM concurrency memory model

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>

On Monday 26 April 2010 14:03:35 Chandler Carruth wrote:
> > 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.
Good.
> 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.
Yep.
> 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.
Vector atomics are extremely useful on architectures that support them.

I'm not sure we need atomicity across vector elements, so decomposing
shouldn't be a problem, but I will have to think about it a bit.

                         -Dave

On 26 April 2010 21:09, David Greene <dag at cray.com>
wrote:
> Vector atomics are extremely useful on architectures that support them.
>
> I'm not sure we need atomicity across vector elements, so decomposing
> shouldn't be a problem, but I will have to think about it a bit.
What is the semantics for vectorization across atomic vector operations?

Suppose I atomically write in thread 1 and read in thread 2, to a
vector with 64 elements. If I do automatic vectorization, it'd naively
be converted into N operations of 64/N-wide atomically writes and
reads, but not necessarily reading block k on thread 2 would happen
before writing it on thread 1, supposing reads are much faster than
writes.

I suppose one would have to have great care when doing such
transformations, to keep the same semantics. For instance, splitting
in two loops and putting a barrier between them, thus back to the
original design.


cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

On Mon, Apr 26, 2010 at 1:09 PM, David Greene <dag at cray.com>
wrote:
> On Monday 26 April 2010 14:03:35 Chandler Carruth wrote:
>> 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.
>
> Vector atomics are extremely useful on architectures that support them.
I'm curious about the architectures/instructions you're thinking of.
Something like 'lock; movdqa'?
> I'm not sure we need atomicity across vector elements, so decomposing
> shouldn't be a problem, but I will have to think about it a bit.
That's interesting. Naïvely, it seems to violate the whole point of
atomics, since it means their side-effects don't appear atomic to
other threads. We could relax that if it's useful, of course. How do
you imagine specifying the program's constraints on vector/word
tearing?

Jeffrey