core.simd woes

Manu turkeyman at gmail.com
Tue Oct 9 00:50:15 PDT 2012


On 9 October 2012 02:38, F i L <witte2008 at gmail.com> wrote:

> Iain Buclaw wrote:
>
>> I'm refusing to implement any intrinsic that is tied to a specific
>> architecture.
>>
>
> I see. So the __builtin_ia32_***() functions in gcc.builtins are
> architecture agnostic? I couldn't find much documentation about them on the
> web. Do you have any references you could pass on?
>
> I guess it makes sense to just make std.simd the lib everyone uses for a
> "base-line" support of SIMD and let DMD do what it wants with it's
> core.simd lib. It sounds like gcc.builtins is just a layer above core.simd
> anyways. Although now it seems that DMD's std.simd will need a bunch of
> 'static if (architectureX) { ... }' for every GDC builtin... wounder if
> later that shouldn't be moved to (and standerized) a 'core.builtins' module
> or something.
>
> Thanks for the explanation.
>

std.simd already does have a mammoth mess of static if(arch & compiler).
The thing about std.simd is that it's designed to be portable, so it
doesn't make sense to expose the low-level sse intrinsics directly there.
But giving it some thought, it might be nice to produce std.simd.sse and
std.simd.vmx, etc for collating the intrinsics used by different compilers,
and anyone who is writing sse code explicitly might use std.simd.sse to
avoid having to support all different compilers intrinsics themselves.
This sounds like a reasonable approach, the only question is what all these
wrappers will do to the code-gen. I'll need to experiment/prove that out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20121009/cfcc8168/attachment.html>


More information about the Digitalmars-d mailing list