search for: atomic_exchang

...2010 15:59, Jeffrey Yasskin <jyasskin at google.com> wrote: > To be clear, Chandler wasn't suggesting any change to the existing > load and store instructions. Instead, we were wondering if people like > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > atomic_exchange and atomic_add instructions. I see, in that case, I don't have any strong opinion. Maybe new instructions would be simpler and cleaner... I quite like the idea of having more expressive atomic operators, as it'll be easier to map high-level synchronization concepts to IR. cheers, --rena...

...l be more complex > than they are today, and reading them could prove a challenge. To be clear, Chandler wasn't suggesting any change to the existing load and store instructions. Instead, we were wondering if people like the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe atomic_exchange and atomic_add instructions. > 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, > --...

...Yasskin <jyasskin at google.com> wrote: > > To be clear, Chandler wasn't suggesting any change to the existing > > load and store instructions. Instead, we were wondering if people like > > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > > atomic_exchange and atomic_add instructions. > > I see, in that case, I don't have any strong opinion. Maybe new > instructions would be simpler and cleaner... > > I quite like the idea of having more expressive atomic operators, as > it'll be easier to map high-level synchronization con...

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,

On 12/11/2015 01:29 PM, James Y Knight wrote: > > On Fri, Dec 11, 2015 at 3:05 PM, Philip Reames via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> One open question I don't know the answer to: Are there any >> special semantics required from floating point stores which >> aren't met

Hi, I've tagged 3.8.1-rc1, testers can begin testing. -Tom

First off, thanks -- this is a pretty great library and it feels like I'm learning a lot. I'm getting some more experience with libfuzzer and finding that I have a couple of questions: - How does libfuzzer decide to write a new test file? What distinguishes this one from all the other cases for which new test inputs were not written? Must be something about the path taken through the

...a bit of user > help. :) > > Ok, that's good advice. -- -Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150811/0323f018/attachment.html> -------------- next part -------------- #0 atomic_exchange<__sanitizer::atomic_uint32_t> (mo=__sanitizer::memory_order_acquire, v=2, a=0x640000001290) #1 __sanitizer::BlockingMutex::Lock (this=this at entry=0x640000001290) at /home/brian/tmp/testing/llvm_src/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:471 #2 0x000000000044789...

...n at google.com> wrote: > > > To be clear, Chandler wasn't suggesting any change to the existing > > > load and store instructions. Instead, we were wondering if people like > > > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > > > atomic_exchange and atomic_add instructions. > > > > I see, in that case, I don't have any strong opinion. Maybe new > > instructions would be simpler and cleaner... > > > > I quite like the idea of having more expressive atomic operators, as > > it'll be easier to map...