Displaying 3 results from an estimated 3 matches for "mem128".
2010 Apr 27
0
[LLVMdev] Proposal for a new LLVM concurrency memory model
On Monday 26 April 2010 16:09:48 Jeffrey Yasskin wrote:
> > 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'?
Don't think X86. Think traditional vector machines like the Cray X1/X2.
Atomic vector adds and logicals are common
2010 Apr 26
2
[LLVMdev] Proposal for a new LLVM concurrency memory model
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
2015 Jan 25
2
Problem with GTX 970 under Fedora 21
...efi: mem125: type=4, attr=0xf, range=[0x0000000002238000-0x00000000022ba000) (0MB)
[ 0.000000] efi: mem126: type=2, attr=0xf, range=[0x00000000022ba000-0x00000000022bc000) (0MB)
[ 0.000000] efi: mem127: type=4, attr=0xf, range=[0x00000000022bc000-0x000000000232f000) (0MB)
[ 0.000000] efi: mem128: type=3, attr=0xf, range=[0x000000000232f000-0x000000000273e000) (4MB)
[ 0.000000] efi: mem129: type=4, attr=0xf, range=[0x000000000273e000-0x0000000002deb000) (6MB)
[ 0.000000] efi: mem130: type=3, attr=0xf, range=[0x0000000002deb000-0x0000000002ded000) (0MB)
[ 0.000000] efi: mem131: type...