[LLVMdev] Proposal for a new LLVM concurrency memory model
Jeffrey Yasskin
jyasskin at google.com
Mon Apr 26 14:09:48 PDT 2010
On Mon, Apr 26, 2010 at 1:09 PM, David Greene <dag at cray.com> wrote:
> On Monday 26 April 2010 14:03:35 Chandler Carruth wrote:
>> We can allow the IR to represent vectors, but unless hardware supports it,
>> I think lowering these by decomposing them is more than LLVM should try to
>> do. Because of that, I'm not sure we should support vectors as elsewhere
>> they degrade gracefully.
>
> Vector atomics are extremely useful on architectures that support them.
I'm curious about the architectures/instructions you're thinking of.
Something like 'lock; movdqa'?
> I'm not sure we need atomicity across vector elements, so decomposing
> shouldn't be a problem, but I will have to think about it a bit.
That's interesting. Naïvely, it seems to violate the whole point of
atomics, since it means their side-effects don't appear atomic to
other threads. We could relax that if it's useful, of course. How do
you imagine specifying the program's constraints on vector/word
tearing?
Jeffrey
More information about the llvm-dev
mailing list