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...


> 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.

artur

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 :/

On 05/22/14 17:51, Manu via Digitalmars-d wrote:
> 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:
>>> 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.

That is how GCC handles the attributes. Somebody more familiar with gcc
development might give a better answer, but AIUI the reason is that if
you mark a function with one "target" then the compiler shouldn't emit
code for another, possibly unsupported, target.
Yes, this does not really make sense, when /direct/ "cross-target" calls
are allowed. A sane(r) approach would be to support just /indirect/ calls,
but that's not what GCC does.

> 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 :/

/I/ would just use inline asm. The target attributes can be useful when auto-vectorization kicks in etc, though.

artur

On 23 May 2014 04:44, Artur Skawina via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 05/22/14 17:51, Manu via Digitalmars-d wrote:
>> 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:
>>>> 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.
>
> That is how GCC handles the attributes. Somebody more familiar with gcc
> development might give a better answer, but AIUI the reason is that if
> you mark a function with one "target" then the compiler shouldn't emit
> code for another, possibly unsupported, target.
> Yes, this does not really make sense, when /direct/ "cross-target" calls
> are allowed. A sane(r) approach would be to support just /indirect/ calls,
> but that's not what GCC does.
>
>> 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 :/
>
> /I/ would just use inline asm. The target attributes can be useful when auto-vectorization kicks in etc, though.

Impossible to make inline asm efficient. Compiler can't pipeline,
reorder, eliminate redundancies, compound mul+add sequences into madd,
that sort of stuff...
Intrinsics are necessary these days. It's just annoying the intrinsics
don't actually mean what they say they mean.