search for: libatomic_ops

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

...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 7:33 PM, Owen Anderson <resistor at mac.com> wrote: > 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/ > >                              Z...

...mpiler 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 7:33 PM, Owen Anderson <resistor at mac.com> wrote: >> 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/ >...

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

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

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 tried to provided appropriate implementations of the atomic ops (currently memory fence and CAS) for platforms we care about, but my knowledge of these, and my ability to test them, is limited. So, please, if you run on

...r (1): meson: don't use compiler.has_header Emil Velikov (1): Revert "libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86/x86_64" Eric Engestrom (13): freedreno: add missing symbols to symbol-check meson: use pkg-config to detect libatomic_ops meson: make it easy to add headers to check meson: detect alloca.h meson,configure: always define HAVE_OPEN_MEMSTREAM meson,configure: always define HAVE_VISIBILITY meson,configure: always define UDEV meson: replace `if(compiles) have=true` with `have=compiles`...

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 platform, send me a patch. > > I know that Sparc does...

...on all machines with mmap(2) + MAP_ANON/MAP_ANONYMOUS support, so *BSDs shouldn''t be left out. Obviously the Linux-only INET_DIAG/TCP_INFO statistics support in raindrops won''t ever be a requirement in Unicorn. If you''re not using gcc 4+, you might need to install libatomic_ops http://www.hpl.hp.com/research/linux/atomic_ops/ to build raindrops. For more information on raindrops, see the raindrops website http://raindrops.bogomips.org/ and/or email the mailing list if you have questions, comments, patches, etc: raindrops at librelist.org (I''ll also respond...