similar to: [LLVMdev] RFC: Atomics.h

Hi, You might want to use this: http://www.hpl.hp.com/research/linux/atomic_ops/ Zoltan On Sat, May 16, 2009 at 11:11 PM, Owen Anderson <resistor at mac.com> wrote: > Some of you may have noticed that I addedd include/llvm/System/Atomics.h to > the repository briefly, which will be used for adding support for threading > in LLVM. > > I have

Surprisingly enough, libatomic_ops doesn't define just a hardware memory fence call as far as I can tell. --Owen On May 16, 2009, at 3:00 PM, Zoltan Varga wrote: > Hi, > > You might want to use this: > > http://www.hpl.hp.com/research/linux/atomic_ops/ > > Zoltan > > On Sat, May 16, 2009 at 11:11 PM, Owen Anderson <resistor at

What would you do with a just-hardware memory fence? If the compiler's free to move operations over the hardware fence, that seems to defeat the purpose. C++0X provides a compiler-only fence, and a hardware+compiler fence, but no hardware-only fence, I believe for this reason. See <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf>, section 29.8. On Sat, May 16, 2009 at

Jeffrey Yasskin wrote: > What would you do with a just-hardware memory fence? If the compiler's > free to move operations over the hardware fence, that seems to defeat > the purpose. If your compiler memory fence (gcc's __sync_synchronize()) doesn't distinguish different kinds of fencing requirements, and your platform has different hardware fences with different costs

OK, I've enhanced Atomic.h by pulling in a bunch of implementations from libatomic_ops, and others that I could figure out on my own. Again, my plea: PLEASE TRY THIS OUT ON YOUR PLATFORM, AND SEND ME PATCHES IF IT DOESN'T WORK! Similarly, if you think the implementation could be improved for your platform, send me a patch. I know that Sparc doesn't work currently (no CAS

Owen Anderson wrote: > Some of you may have noticed that I addedd include/llvm/System/Atomics.h > to the repository briefly, which will be used for adding support for > threading in LLVM. Just out of curiosity, is there a design document somewhere for the plan for threading? Also, atomic ops are usually pretty low level things used for nonblocking algorithms or to build higher level

On May 16, 2009, at 7:47 PM, Luke Dalessandro wrote: > Owen Anderson wrote: >> Some of you may have noticed that I addedd include/llvm/System/ >> Atomics.h >> to the repository briefly, which will be used for adding support for >> threading in LLVM. > > Just out of curiosity, is there a design document somewhere for the > plan > for threading? Not as

On May 16, 2009, at 10:01 PM, Owen Anderson wrote: > OK, I've enhanced Atomic.h by pulling in a bunch of implementations > from libatomic_ops, and others that I could figure out on my own. > > Again, my plea: PLEASE TRY THIS OUT ON YOUR PLATFORM, AND SEND ME > PATCHES IF IT DOESN'T WORK! Similarly, if you think the > implementation could be improved for your

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).

On May 17, 2009, at 12:32 PM, Chris Lattner wrote: > Owen, I would really rather that you didn't take this path. Threading > support in LLVM should always be optional: it should be possible to > use LLVM on systems where we don't have support for threading > operations. Indeed, some systems don't support threads! I'm not trying to make it required. I had provided

Owen Anderson wrote: > > On May 16, 2009, at 7:47 PM, Luke Dalessandro wrote: > >> Also, atomic ops are usually pretty low level things used for >> nonblocking algorithms or to build higher level locking constructs. Is >> that the plan here too? It seems like you'd want to avoid anything too >> fancy since LLVM has to run on so many different architectures

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 May 28, 2009, at 6:03 PM, Jonathan Ragan-Kelley wrote: > In the current trunk, System/Atomic.[h,cpp] define void > llvm::sys::MemoryFence(). This conflicts with the MemoryFence macro in > <windows.h> and (since it's a preprocessor macro, and not a scoped > function definition) causes the sys::MemoryFence definition on > Atomic.cpp:23 to explode, as it's

Yes, indeed. On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote: > > Wait, it defines MemoryFence() AND MemoryBarrier()?? > > Sheesh, they had to take all the reasonable names.  :-/

On May 17, 2009, at 5:23 AM, Luke Dalessandro wrote: > Owen Anderson wrote: >> >> On May 16, 2009, at 7:47 PM, Luke Dalessandro wrote: >> >>> Also, atomic ops are usually pretty low level things used for >>> nonblocking algorithms or to build higher level locking >>> constructs. Is >>> that the plan here too? It seems like you'd want

Hi, Here is an updated version of the patch using address space 257. Zoltan On Mon, May 4, 2009 at 11:36 PM, Shantonu Sen <ssen at apple.com> wrote: > Maybe 257 would be better (or other unused), because of r70197, which gives > special behavior for <256 > > Shantonu Sen > ssen at apple.com > > Sent from my Mac Pro > > > On May 4, 2009,

Hi, Attached is the final version of the patch, adding the requested FIXME. If this is ok, can somebody check it in ? thanks Zoltan On Tue, Dec 9, 2008 at 9:58 PM, Bill Wendling <isanbard at gmail.com> wrote: > On Tue, Dec 9, 2008 at 6:11 AM, Zoltan Varga <vargaz at gmail.com> wrote: >> Hi, >>

Hi, I don't intentionally want to induce a tramp, the load null is created by an llvm optimization pass from code like: v = null; ..... v.Call (); Zoltan On Sat, Sep 5, 2009 at 11:39 PM, Bill Wendling <isanbard at gmail.com> wrote: > Hi Zoltan, > > We've come across this before where people meant to induce a trap by > dereferencing a null. It