• Manu via Digitalmars-d (31/31) May 22 2014 This issue has been there for a long time, and std.simd has been

Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:

This issue has been there for a long time, and std.simd has been
blocked on this for a year.
https://issues.dlang.org/show_bug.cgi?id=10193

Can anyone chime in and suggest options, or perhaps how to fix?


Also, to the LDC guys: GDC supports a UDA, eg.  attribute("target",
"sse2"), which will resolve as regular GCC attributes: __attribute__
((__target__ ("sse2"))).
I use this, eg:

   attribute("target", "avx")
  float4 func(float4 arg)
  {
    return arg;
  }

To control compiler code generation for various SIMD hardware feature
availability.

One of the design goals for std.simd was that in the spirit of D's
powerful templates and meta-programming, I wanted to be able to create
branches for different SIMD versions conveniently, and I do this with
a cascading SIMDVer template arg that is supplied to all SIMD
functions.

This is easy to implement in DMD, since they are just raw intrinsics,
but in GCC, the intrinsics are re-interpreted conceptually; they don't
just emit the opcode they represent.
What this means is, whatever SIMD version you supply on the command
line, all codegen will target that SIMD version, regardless of what
intrinsics you call.
To address this, in GCC, you can use attributes or pragma's to specify
the code-gen on a per-function basis, ie: __attribute__ ((__target__
("sse2"))), or #pragma GCC target ("sse2")
To access this with GDC, I use the code above.

The question is, how does this work in LDC? And can this same approach be used?