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

Hi all,

Chandler, Owen, and I have written up a proposal for a new memory
model and atomic intrinsics in LLVM, which will make it possible to
support Java and the upcoming C++0x standard. The proposed changes to
the LangRef are at
<http://docs.google.com/View?docID=ddb4mhxz_22dz5g98dd&revision=_latest>,
and a rationale for some of the more surprising changes is at
<http://docs.google.com/View?docID=ddb4mhxz_24gh4ksvgh&revision=_latest>.
You're the first group to see this, so it's likely to need some
significant fixes based on your feedback. Let us know what you think.

Thanks,
Jeffrey, Chandler, and Owen

One question I had for LLVM folks while we were working on this: does it
make sense to transition the atomic operations to instructions instead of
intrinsics? I'm not sold on this in either direction, I'd just like to
get
people's thoughts on it.

Certainly for languages such as Java, they will make up a surprisingly large
chunk of the loads and stores, and instructions have much mor flexibility in
terms of syntax. On the flip side, it's a lot of plumbing IIRC, and we'd
really need to stick to the very minimal set of operations, supporting more
obscure ones by pattern matching or intrinsics.

On Sun, Apr 25, 2010 at 7:26 PM, Jeffrey Yasskin <jyasskin at
google.com>wrote:
> Hi all,
>
> Chandler, Owen, and I have written up a proposal for a new memory
> model and atomic intrinsics in LLVM, which will make it possible to
> support Java and the upcoming C++0x standard. The proposed changes to
> the LangRef are at
>
<http://docs.google.com/View?docID=ddb4mhxz_22dz5g98dd&revision=_latest>,
> and a rationale for some of the more surprising changes is at
>
<http://docs.google.com/View?docID=ddb4mhxz_24gh4ksvgh&revision=_latest>.
> You're the first group to see this, so it's likely to need some
> significant fixes based on your feedback. Let us know what you think.
>
> Thanks,
> Jeffrey, Chandler, and Owen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100426/115db55b/attachment.html>

On 26 April 2010 10:49, Chandler Carruth <chandlerc at google.com>
wrote:
> Certainly for languages such as Java, they will make up a surprisingly
large
> chunk of the loads and stores, and instructions have much mor flexibility
in
> terms of syntax. On the flip side, it's a lot of plumbing IIRC, and
we'd
> really need to stick to the very minimal set of operations, supporting more
> obscure ones by pattern matching or intrinsics.
If you add it to the instructions, their syntax will be more complex
than they are today, and reading them could prove a challenge.

IMHO, we should keep it simple. I agree that multi-task is ubiquitous
nowadays but the detailed implementation might vary considerably from
language to language and making it explicit only helps, at least in
the beginning.

cheers,
--renato

http://systemcall.org/

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

On Sunday 25 April 2010 21:26:47 Jeffrey Yasskin wrote:
> Hi all,
>
> Chandler, Owen, and I have written up a proposal for a new memory
> model and atomic intrinsics in LLVM, which will make it possible to
> support Java and the upcoming C++0x standard. The proposed changes to
> the LangRef are at
>
<http://docs.google.com/View?docID=ddb4mhxz_22dz5g98dd&revision=_latest>,
I just started reading this.  Should I interpret "may not" as
"must not"
throughout this document?

The language of this proposal needs to be much clearer.  "may not" can
be interpreted in at least two different, opposite ways.

                        -Dave

On Apr 26, 2010, at 11:28 AM, David Greene wrote:
> On Sunday 25 April 2010 21:26:47 Jeffrey Yasskin wrote:
>> Hi all,
>> 
>> Chandler, Owen, and I have written up a proposal for a new memory
>> model and atomic intrinsics in LLVM, which will make it possible to
>> support Java and the upcoming C++0x standard. The proposed changes to
>> the LangRef are at
>>
<http://docs.google.com/View?docID=ddb4mhxz_22dz5g98dd&revision=_latest>,
> 
> I just started reading this.  Should I interpret "may not" as
"must not"
> throughout this document?
> 
> The language of this proposal needs to be much clearer.  "may
not" can
> be interpreted in at least two different, opposite ways.
The "must not" reading is correct.  I've changed the document to
reflect that.  Thanks for pointing it out.

--Owen

On Sunday 25 April 2010 21:26:47 Jeffrey Yasskin wrote:
> Hi all,
>
> Chandler, Owen, and I have written up a proposal for a new memory
> model and atomic intrinsics in LLVM, which will make it possible to
> support Java and the upcoming C++0x standard. The proposed changes to
> the LangRef are at
>
<http://docs.google.com/View?docID=ddb4mhxz_22dz5g98dd&revision=_latest>,
What's a "trap" and "trap value?"  Is it some C++0X or
Java thing?
It needs to be defined.
>From the rationale, "trap" sounds like the IA64 trap value. 
That's
too target-specific for a proposal like this.  Why not just say that
the use of an uninitialized value is undefined and leave it at that?

                           -Dave

Hi David-

On 26 Apr 2010, at 21:05, David Greene wrote:
> What's a "trap" and "trap value?"  Is it some C++0X
or Java thing?
> It needs to be defined.
See LangRef.html

Alistair

> Hi all,
> 
> Chandler, Owen, and I have written up a proposal for a new memory
> model and atomic intrinsics in LLVM, which will make it possible to
> support Java and the upcoming C++0x standard. The proposed changes to
> the LangRef are at
>
<http://docs.google.com/View?docID=ddb4mhxz_22dz5g98dd&revision=_latest
> >,
> and a rationale for some of the more surprising changes is at
>
<http://docs.google.com/View?docID=ddb4mhxz_24gh4ksvgh&revision=_latest
> >.
>From a first glance, it looks like double-wide compare exchange is missing.
See http://en.wikipedia.org/wiki/ABA_problem for an example of where it's
very useful.

Mark

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 8614 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100426/e8c65338/attachment.bin>

On Mon, Apr 26, 2010 at 1:28 PM, Lacey, Mark <mark.lacey at intel.com>
wrote:
>> Hi all,
>>
>> Chandler, Owen, and I have written up a proposal for a new memory
>> model and atomic intrinsics in LLVM, which will make it possible to
>> support Java and the upcoming C++0x standard. The proposed changes to
>> the LangRef are at
>>
<http://docs.google.com/View?docID=ddb4mhxz_22dz5g98dd&revision=_latest
>> >,
>> and a rationale for some of the more surprising changes is at
>>
<http://docs.google.com/View?docID=ddb4mhxz_24gh4ksvgh&revision=_latest
>> >.
>
> From a first glance, it looks like double-wide compare exchange is missing.
> See http://en.wikipedia.org/wiki/ABA_problem for an example of where
it's
> very useful.
You'll be able to get at double-wide compare exchange on 64-bit
platforms with @llvm.atomic.cmp.exchange.i128.p0i128 (same as you can
now). If your target doesn't support this width, it may explode when
you get to codegen. We don't have any plans for an intrinsic for
Itanium's cmp8xchg16 instruction (since we don't know of a language
that supports it that compiles to LLVM, and it doesn't fit well into
the api for ordinary cmpxchges), but someone could propose that as an
extension later.

The more abstract cmp.exchange on {i8*, i8*} would require extending
how intrinsics work or switching to instructions. For now, I think
casting to i128s will be ok for most frontends.

Thanks for taking a look,
Jeffrey