On 9 October 2012 00:52, David Nadlinger <s...@klickverbot.at> wrote: > On Monday, 8 October 2012 at 21:36:08 UTC, F i L wrote: > >> Iain Buclaw wrote: >>> >>> float a = 1, b = 2, c = 3, d = 4; >>> float4 f = [a,b,c,d]; >>> >>> ===> >>> movss -16(%rbp), %xmm0 >>> movss -12(%rbp), %xmm1 >> >> >> Nice, not even DMD can do this yet. Can these changes be pushed upstream? > > > No, the actual codegen is compilers-specific (and apparently wrong in the > case of GDC, if this is the actual piece of code emitted for the code > snippet). > > > >> On a side note, I understand GDC doesn't support the core.simd.__simd(...) >> command, and I'm sure you have good reasons for this. However, it would >> still be nice if: >> >> a) this interface was supported through function-wrappers, or.. >> b) DMD/LDC could find common ground with GDC in SIMD instructions > > > LDC won't support core.simd.__simd in the forseeable future either. The > reason is that it is a) untyped and b) highly x86-specific, both of which > make it hard to integrate with LLVM – __simd is really just a glorified > inline assembly expression (hm, this makes me think, maybe it could be > implemented quite easily in terms of a transformation to LLVM inline > assembly expressions…). > > >> Is core.simd designed to really never be used and Manu's std.simd is >> really the starting place for libraries? (I believe I remember him >> mentioning that) > > > With all due respect to Walter, core.simd isn't really "designed" much at > all, or at least this isn't visible in its current state – it rather seems > like a quick hack to get some basic SIMD code working with DMD (but beware > of ICEs). > > Walter, if you are following this thread, do you have any plans for SIMD on > non-x86 platforms? > > David
Vector types already support the same basic operations that can be done on D arrays. So that itself guarantees cross platform. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
