Jeffrey Yasskin
2010-Apr-26 02:26 UTC
[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
Chandler Carruth
2010-Apr-26 09:49 UTC
[LLVMdev] Proposal for a new LLVM concurrency memory model
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>
Renato Golin
2010-Apr-26 10:14 UTC
[LLVMdev] Proposal for a new LLVM concurrency memory model
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
David Greene
2010-Apr-26 18:28 UTC
[LLVMdev] Proposal for a new LLVM concurrency memory model
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
Owen Anderson
2010-Apr-26 18:43 UTC
[LLVMdev] Proposal for a new LLVM concurrency memory model
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
David Greene
2010-Apr-26 20:05 UTC
[LLVMdev] Proposal for a new LLVM concurrency memory model
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'stoo 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
Alistair Lynn
2010-Apr-26 20:15 UTC
[LLVMdev] Proposal for a new LLVM concurrency memory model
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
Lacey, Mark
2010-Apr-26 20:28 UTC
[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 > >.>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>
Jeffrey Yasskin
2010-Apr-26 20:54 UTC
[LLVMdev] Proposal for a new LLVM concurrency memory model
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
Possibly Parallel Threads
- [LLVMdev] Proposal for a new LLVM concurrency memory model
- [LLVMdev] Proposal for a new LLVM concurrency memory model
- [LLVMdev] Proposal for a new LLVM concurrency memory model
- [LLVMdev] Reviving the new LLVM concurrency model
- [LLVMdev] Reviving the new LLVM concurrency model