On 22 May 2014 23:53, Artur Skawina via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
> On 05/22/14 12:54, Manu via Digitalmars-d wrote:
>> 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?
>
> It's not entirely clear from that report what exactly you need, but
> one way would be:
>
> enum targets = [ "hello":"sse2", "world":"avx" ];
>
> template func(string Target)
> {
> @attribute("target", targets[Target]) T func(T)(T arg)
> {
> return arg;
> }
> }
>
> Using CTFE instead of the above AA look-up could be more natural,
> but that does not work here, as it crashes the frontend...
Oh I see, you moved the second template arg to an inner template... I
didn't think of that.
I'll give that a shot.
>> 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.
>
> Keep in mind that GDC will not inline those functions into callers
> marked with a different (or no) target attribute.
Umm... really? Why?
Well, that's a colossal failure.
So... is it impossible then to force the compiler to emit specific
opcodes in GCC? The problem is the intrinsics don't actually map to
opcodes, they are reinterpreted however the compiler likes :/
