core.simd woes
David Nadlinger
see at klickverbot.at
Mon Oct 8 16:52:08 PDT 2012
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
More information about the Digitalmars-d
mailing list