Displaying 20 results from an estimated 24 matches for "atomic_load".
2009 Oct 30
2
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
...mpilation stub should spin waiting on a lock
(implemented using atomics), and the compilation callback should
execute while holding the lock just before patching the callsite, so it
would look like this in pseudocode:
callsite_patch_state = 0;// for each callsite one byte of memory
callsite:
if (atomic_load(&callsite_patch_state) == 2) {
//fast-path: already compiled and patched
patchsite:
jmp <nop nop nop nop nop nop nop nop> // will be patched
}
// not yet patched, it may already be compiling
if (atomic_test_and_set(&callsite_patch_state, 0, 1) == 0) {
// not yet co...
2009 Nov 01
0
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
...; option I mentioned in the bug.
Would you add it to the bug so we don't lose it?
I think we can put the entire "not yet patched" branch inside the
compilation callback to minimize the code size impact:
callsite_patch_state = 0;// for each callsite one byte of memory
callsite:
if (atomic_load(&callsite_patch_state) != 2) {
call CompilationCallback // Doesn't return until the patchsite is patched.
}
//fast- and slow-path: already compiled and patched
patchsite:
call <nop nop nop nop nop nop nop nop> // will be patched
> callsite_patch_state = 0;// for each call...
2010 Apr 26
2
[LLVMdev] Proposal for a new LLVM concurrency memory model
On 26 April 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 m...
2015 Dec 11
2
RFC: Extending atomic loads and stores to floating point and vector types
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
2010 Apr 26
0
[LLVMdev] Proposal for a new LLVM concurrency memory model
...; If you add it to the instructions, their syntax will 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, a...
2010 Apr 26
0
[LLVMdev] Proposal for a new LLVM concurrency memory model
...:19:06 Renato Golin wrote:
> On 26 April 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,...
2012 Aug 24
0
[LLVMdev] Let's get rid of neverHasSideEffects
...d no pattern and the latter, when mayStore was implied in the pattern.
>
> If only TableGen wouldn't warn about non-conflicting attributes at least…
That warning has been removed now, and you should be able to clean up your classes.
I also filed PR13693 for you. It's a bug to lower atomic_load to an instruction without mayStore - atomic loads can't be reordered.
/jakob
2010 Apr 26
2
[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,
2014 May 24
3
[LLVMdev] Why can't atomic loads and stores handle floats?
Looking through the documentation, I discovered that atomic loads and
stores are only supported for integer types. Can anyone provide some
background on this? Why is this true?
Currently, given code:
std::atomic<float> aFloat;
void foo() {
float f = atomic_load(&aFloat);
..
}
Clang generates code like:||
%"struct.std::atomic.2" = type { float }
@aFloat = global %"struct.std::atomic.2" zeroinitializer, align 4
define void @foo() {
%1 = load atomic i32* bitcast (%"struct.std::atomic.2"* @aFloat to
i32*) seq_cst, al...
2012 Aug 22
2
[LLVMdev] Let's get rid of neverHasSideEffects
On 08/21/12 16:49, Jim Grosbach wrote:
>
> I like that. Possibly with the addition that we can filter by a specific property. -Winfer=neverHasSideEffects, e.g., would only show when that specific property is inferred.
>
> Beyond that, I don't see an alternative to an audit of the instructions that get flagged by such a warning. :(
This proposal would certainly make my life easier
2009 Oct 29
0
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray
<nicolas.geoffray at lip6.fr> wrote:
> Hi Jeffrey,
>
> Jeffrey Yasskin wrote:
>>
>> Cool, I'll start implementing it.
>>
>
> Great! Thanks.
>
> Just to clarify things: on my end, it doesn't really matter what is the
> default behavior, as long as vmkit can continue to have the existing
>
2009 Nov 01
1
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
...d you add it to the bug so we don't lose it?
>
> I think we can put the entire "not yet patched" branch inside the
> compilation callback to minimize the code size impact:
>
> callsite_patch_state = 0;// for each callsite one byte of memory
>
> callsite:
> if (atomic_load(&callsite_patch_state) != 2) {
> call CompilationCallback // Doesn't return until the patchsite is patched.
> }
> //fast- and slow-path: already compiled and patched
> patchsite:
> call <nop nop nop nop nop nop nop nop> // will be patched
>
>
Yes, tha...
2016 Jun 04
4
Gluing arbitrary nodes together
...et can only have one core, it is sufficient to:
- Save the status register
- Disable interrupts
- Do the nonatomic LOAD/STORE/SWAP/ADD
- Restore the status register
I’d really like to be able to do this at the IR level. What I want to do is
write a custom lowering hook to convert ISD::ATOMIC_LOAD into a standard
ISD::LOAD with the save/restore/interrupt nodes glued to it.
Here’s what I have so far:
// Store `SREG`
auto Save = DAG.getCopyFromReg(DAG.getEntryNode(), DL, AVR::SREG, MVT::i8);
// Disable interrupts (`clr` is equivalent to `bclr 7`).
auto ClearInterrupts = DAG.getNode(...
2014 Apr 18
2
[LLVMdev] multithreaded performance disaster with -fprofile-instr-generate (contention on profile counters)
...ath overhead is only a virtually
> zero overhead (if implemented properly in the compiler) atomic consume load:
>
> const int maxshard = 4096;
> uint64* shard[maxshard];
> atomic<int> shardmask;
>
> void inline inccounter(int idx)
> {
> int shardidx = gettid() & atomic_load(&shardmask, memory_order_consume);
> shard[shardidx][idx]++;
> }
>
> int pthread_create(...)
> {
> if (updateshardcount()) {
> shardlock();
> if (updateshardcount()) {
> int newcount = computeshardcount();
> for (int i = oldcount; i < newcount; i++)
> shar...
2016 Jun 08
9
3.8.1-rc1 has been tagged
Hi,
I've tagged 3.8.1-rc1, testers can begin testing.
-Tom
2009 Oct 29
3
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
Hi Jeffrey,
Jeffrey Yasskin wrote:
> Cool, I'll start implementing it.
>
Great! Thanks.
Just to clarify things: on my end, it doesn't really matter what is the
default behavior, as long as vmkit can continue to have the existing
behavior of lazy compilation. With Chris' solution, I was wondering how
you would implement the getPointerToFunction{Eager, Lazy} functions when
2016 Feb 29
0
[Release-testers] [3.8 Release] RC3 has been tagged
...ss.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_init.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_is_lock_free.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_load.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_load_explicit.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_store.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations...
2010 Apr 26
3
[LLVMdev] Proposal for a new LLVM concurrency memory model
...wrote:
> > On 26 April 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 mor...
2014 Apr 18
2
[LLVMdev] multithreaded performance disaster with -fprofile-instr-generate (contention on profile counters)
...in the compiler) atomic
>>> consume load:
>>>
>>> const int maxshard = 4096;
>>> uint64* shard[maxshard];
>>> atomic<int> shardmask;
>>>
>>> void inline inccounter(int idx)
>>> {
>>> int shardidx = gettid() & atomic_load(&shardmask, memory_order_consume);
>>> shard[shardidx][idx]++;
>>> }
>>>
>>> int pthread_create(...)
>>> {
>>> if (updateshardcount()) {
>>> shardlock();
>>> if (updateshardcount()) {
>>> int newcount = computesh...
2014 May 26
3
[LLVMdev] Why can't atomic loads and stores handle floats?
...entation, I discovered that atomic loads and
>> stores are only supported for integer types. Can anyone provide some
>> background on this? Why is this true?
>>
>> Currently, given code:
>> std::atomic<float> aFloat;
>> void foo() {
>> float f = atomic_load(&aFloat);
>> ..
>> }
>>
>> Clang generates code like:||
>> %"struct.std::atomic.2" = type { float }
>> @aFloat = global %"struct.std::atomic.2" zeroinitializer, align 4
>>
>> define void @foo() {
>> %1 = load atomic i...