similar to: [LLVMdev] Time to think about a concurrency-aware LLVM memory model?

I agree this is an important problem, but the goals here need to be defined carefully. Defining a single memory model (or a set of models) for the LLVM IR would be a long and complex process and probably only worthwhile for projects that use LLVM to build a complete persistent bytecode language (with parallel features) and virtual machine. Note that the LLVM infrastructure has

Torvald Riegel wrote: > Hi, > > I'd like to see support for something like this. I have some comments, and I > think there is existing work that you can reuse. "reuse within the compiler." > "While the processor may spin and attempt the atomic operation more than once > before it is successful, research indicates this is extremely uncommon." > I

On Monday 09 July 2007 19:33, Scott Michel wrote: > Torvald Riegel wrote: > > Hi, > > > > I'd like to see support for something like this. I have some comments, > > and I think there is existing work that you can reuse. > > "reuse within the compiler." within the LLVM compiler framework, to be precise. > > > "While the processor may

Hi, I'd like to see support for something like this. I have some comments, and I think there is existing work that you can reuse. TAS and CAS are _not_ theoretically equivalent. TAS is weaker because it can solve consensus in a nonblocking way only for 2 threads (it has consensus number 2), whereas CAS can solve consensus for any number of threads (infinite consensus number).

Hello, After a fair amount of research and work, I have put together a concrete proposal for LLVM representations of atomic operations and synchronization constructs. These aim to provide the minimal functionality in the IR for representing the hardware constructs that threading libraries and parallel programming rely on. http://chandlerc.net/llvm_atomics.html While I am no expert on the

On 2/21/08, Torvald Riegel <torvald at se.inf.tu-dresden.de> wrote: > why is the intrinsic name not CAS? And having another version that returns > just a bool might be better in some cases ( 1. does CAS return the value on > all architectures? 2. you can just jump based on a flag and don't need to > compare it again). Just my 2 cents though ... I was going from

On Wednesday 20 February 2008 01:51, Andrew Lenharth wrote: > Anyone have an idea? The patch as it stands is attached below. X86 > is a pseudo instruction because the necessary ones and prefixes aren't > in the code gen yet, but I would imagine they will be (so ignore that > ugliness). The true ugliness can be seen in the alpha impl which open > codes it, including a couple

I was working on compare and swap and ran into the following problem. Several architectures implement this with a load locked, store conditional sequence. This is good, for those archs I can write generic code to legalize a compare and swap (and most other atomic ops) to load locked store conditional sequences (then the arch only had to give the instr for ldl, stc to support all atomic ops (this

> > > "While the processor may spin and attempt the atomic operation more than > > > once before it is successful, research indicates this is extremely > > > uncommon." I don't understand this sentence, what do you mean? > > > > I'm not sure I can pinpoint the paper from which the statement is based, > > but I seem to recall something

On 7/12/07, Torvald Riegel <torvald at se.inf.tu-dresden.de> wrote: > Here are some comments, quotes are from the draft. > > > an operation based constraint cannot guard other operations > > I think constraints associated with a particular instruction usually apply > to this instruction and previous/subsequent instructions, so this wouldn't > be true. This is the

Hello, This is the second major revision of the atomic proposal for LLVM. I will try and give a brief overview of the motivating changes, but a greater portion of the text has changed, along with some changes to the proposed additions. http://chandlerc.net/llvm_atomics.html - The proposal has been rewritten to better delineate the goals and purposes of LLVM, and these additions to LLVM. The why

Here are some comments, quotes are from the draft. > an operation based constraint cannot guard other operations I think constraints associated with a particular instruction usually apply to this instruction and previous/subsequent instructions, so this wouldn't be true. This is the case in the atomic_ops model, and also on ia64 I think. > The single instruction constraints can,

On Thu, Feb 21, 2008 at 9:34 AM, Andrew Lenharth <andrewl at lenharth.org> wrote: > On 2/21/08, Torvald Riegel <torvald at se.inf.tu-dresden.de> wrote: > > why is the intrinsic name not CAS? And having another version that returns > > just a bool might be better in some cases ( 1. does CAS return the value on > > all architectures? 2. you can just jump based

Torvald Riegel wrote: > On Wednesday 20 February 2008 01:51, Andrew Lenharth wrote: >> Anyone have an idea? The patch as it stands is attached below. X86 >> is a pseudo instruction because the necessary ones and prefixes aren't >> in the code gen yet, but I would imagine they will be (so ignore that >> ugliness). The true ugliness can be seen in the alpha impl

Torvald Riegel wrote: > First of all, I know LL/SC. Did I say it's equivalent to get-and-set? No. > So what are you trying to say, why is the paragraph in the proposal? You > seem to be speculating about architectures in general in one paragraph. > IMHO, I wouldn't try that, because I would have to be either imprecise or > don't state anything new. I was rebutting

Hi, I would like to know whether the community is interested in getting support for Transactional Memory (TM) merged in upstream LLVM. TM basically gives you transaction properties (eg, virtually atomic + isolated execution) for ordinary program code. Thus, to make incrementing a counter thread-safe, you could say __transaction { counter++; } and the compiler would transform this code so

On Tuesday 26 October 2010 14:33:02 Duncan Sands wrote: > > transaction properties (eg, virtually atomic + isolated execution) for > > ordinary program code. Thus, to make incrementing a counter thread-safe, > > you could say __transaction { counter++; } and the compiler would > > transform this code so that it uses a TM library, which in turn does > > concurrency

Hi, Takumi. Your CMake changes seem to be working just fine with the standalone Xcode build. However, the build products are still being put in bin/Debug instead of Debug/bin. Was that supposed to change yet? Maybe Xcode needs different settings? (I think I looked into this once and it was non-trivial to change for Xcode, so if it's working for you I guess you don't need to worry about

On Dec 17, 2013, at 9:32 , Jordan Rose <jordan_rose at apple.com> wrote: > > On Dec 17, 2013, at 9:24 , Jordan Rose <jordan_rose at apple.com> wrote: > >> Hi, Takumi. Your CMake changes seem to be working just fine with the standalone Xcode build. However, the build products are still being put in bin/Debug instead of Debug/bin. Was that supposed to change yet? Maybe

On 7/9/07, John Criswell <criswell at cs.uiuc.edu> wrote: > 1) You may want to consider adding atomic load-<bitwise operation>-store > instructions in addition to load-<add/subtract> instructions. The Linux > kernel uses these for atomic bit setting/clearing, and on many systems > they can be implemented more efficiently using special assembly > instructions.