core.simd woes

[Iain Buclaw]

On 9 October 2012 00:52, David Nadlinger <see at 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';