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