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

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.

cheers,
--renato

http://systemcall.org/

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

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.

                             -Dave

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>