Actually, I think the C counterpart is actually
__attribute__((__target__("targetstring"))), with bonus underscores ;)


On 27 May 2013 18:15, Manu <turkeyman@gmail.com> wrote:

> So we talked about this at DConf.
>
> Working on std.simd, I need to be able to change the target parameter on a
> per-function basis.
> GCC supports this via: __attribute__((target("sse2"))) for instance.
>
> I need the ability to set this from D, but the trick is, I need to be able to set the target string according to a template arg.
>
> Eg:
>   enum Targets { SSE2, SSE3 };
>   enum targets[] = [ "sse2", "sse3" ];
>
>   @attribute("target", targets[T]) // <- attribute needs to refer to the
> template arg T
>   void func(Targets T)();
>
>
>   {
>     // this way, it is possibly to produce dynamic selection of code paths
> optimised for different CPU features (a task which is usually very tedious
> in C/C++)
>     func!(Targets.SSE2)();
>   }
>
>

On 27 May 2013 09:21, Manu <turkeyman@gmail.com> wrote:
> Actually, I think the C counterpart is actually
> __attribute__((__target__("targetstring"))), with bonus underscores ;)
>
>
> On 27 May 2013 18:15, Manu <turkeyman@gmail.com> wrote:
>>
>> So we talked about this at DConf.
>>
>> Working on std.simd, I need to be able to change the target parameter on a
>> per-function basis.
>> GCC supports this via: __attribute__((target("sse2"))) for instance.
>>
>> I need the ability to set this from D, but the trick is, I need to be able to set the target string according to a template arg.
>>
>> Eg:
>>   enum Targets { SSE2, SSE3 };
>>   enum targets[] = [ "sse2", "sse3" ];
>>
>>   @attribute("target", targets[T]) // <- attribute needs to refer to the
>> template arg T
>>   void func(Targets T)();
>>
>>

I'll turn on rudimentary support, as the backend takes care of pretty much all the work.  But I think this should work as UDAs work off CTFE with string manipulation.


>>   {
>>     // this way, it is possibly to produce dynamic selection of code paths
>> optimised for different CPU features (a task which is usually very tedious
>> in C/C++)
>>     func!(Targets.SSE2)();
>>   }
>>
>

As a small experiment, I could turn on versioning for these functions...  However is only available for x86 targets.

eg:

void foo() @target("sse")    // mangled 'foo.sse'
{
}

void foo() @target("mmx")   // mangled 'foo.mmx'
{
}



Regards
--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 27 May 2013 19:01, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 27 May 2013 09:21, Manu <turkeyman@gmail.com> wrote:
> > Actually, I think the C counterpart is actually
> > __attribute__((__target__("targetstring"))), with bonus underscores ;)
> >
> >
> > On 27 May 2013 18:15, Manu <turkeyman@gmail.com> wrote:
> >>
> >> So we talked about this at DConf.
> >>
> >> Working on std.simd, I need to be able to change the target parameter
> on a
> >> per-function basis.
> >> GCC supports this via: __attribute__((target("sse2"))) for instance.
> >>
> >> I need the ability to set this from D, but the trick is, I need to be
> able
> >> to set the target string according to a template arg.
> >>
> >> Eg:
> >>   enum Targets { SSE2, SSE3 };
> >>   enum targets[] = [ "sse2", "sse3" ];
> >>
> >>   @attribute("target", targets[T]) // <- attribute needs to refer to the
> >> template arg T
> >>   void func(Targets T)();
> >>
> >>
>
> I'll turn on rudimentary support, as the backend takes care of pretty much all the work.  But I think this should work as UDAs work off CTFE with string manipulation.
>
>
> >>   {
> >>     // this way, it is possibly to produce dynamic selection of code
> paths
> >> optimised for different CPU features (a task which is usually very
> tedious
> >> in C/C++)
> >>     func!(Targets.SSE2)();
> >>   }
> >>
> >
>
> As a small experiment, I could turn on versioning for these functions...  However is only available for x86 targets.
>
> eg:
>
> void foo() @target("sse")    // mangled 'foo.sse'
> {
> }
>
> void foo() @target("mmx")   // mangled 'foo.mmx'
> {
> }
>

I'm confused, are you suggesting to handle these particular values
explicitly in gdc?
I was giving examples of the code I want to write (and work). I can handle
this in std.simd.
I don't think there's any reason to handle arch-specific cases like that in
gdc.

Or rather, was the point you were trying to make here the possible support
of a @target() attribute (which affects the mangling), rather than
@attribute("target")?

On 27 May 2013 11:18, Manu <turkeyman@gmail.com> wrote:
> On 27 May 2013 19:01, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>>
>> On 27 May 2013 09:21, Manu <turkeyman@gmail.com> wrote:
>> > Actually, I think the C counterpart is actually
>> > __attribute__((__target__("targetstring"))), with bonus underscores ;)
>> >
>> >
>> > On 27 May 2013 18:15, Manu <turkeyman@gmail.com> wrote:
>> >>
>> >> So we talked about this at DConf.
>> >>
>> >> Working on std.simd, I need to be able to change the target parameter
>> >> on a
>> >> per-function basis.
>> >> GCC supports this via: __attribute__((target("sse2"))) for instance.
>> >>
>> >> I need the ability to set this from D, but the trick is, I need to be
>> >> able
>> >> to set the target string according to a template arg.
>> >>
>> >> Eg:
>> >>   enum Targets { SSE2, SSE3 };
>> >>   enum targets[] = [ "sse2", "sse3" ];
>> >>
>> >>   @attribute("target", targets[T]) // <- attribute needs to refer to
>> >> the
>> >> template arg T
>> >>   void func(Targets T)();
>> >>
>> >>
>>
>> I'll turn on rudimentary support, as the backend takes care of pretty much all the work.  But I think this should work as UDAs work off CTFE with string manipulation.
>>
>>
>> >>   {
>> >>     // this way, it is possibly to produce dynamic selection of code
>> >> paths
>> >> optimised for different CPU features (a task which is usually very
>> >> tedious
>> >> in C/C++)
>> >>     func!(Targets.SSE2)();
>> >>   }
>> >>
>> >
>>
>> As a small experiment, I could turn on versioning for these functions...  However is only available for x86 targets.
>>
>> eg:
>>
>> void foo() @target("sse")    // mangled 'foo.sse'
>> {
>> }
>>
>> void foo() @target("mmx")   // mangled 'foo.mmx'
>> {
>> }
>
>
> I'm confused, are you suggesting to handle these particular values
> explicitly in gdc?
> I was giving examples of the code I want to write (and work). I can handle
> this in std.simd.
> I don't think there's any reason to handle arch-specific cases like that in
> gdc.
>
> Or rather, was the point you were trying to make here the possible support
> of a @target() attribute (which affects the mangling), rather than
> @attribute("target")?

OK, if your confused, I won't do it then... :)

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

By 'it', you mean supporting @target? Or handling specific targets + mangling?

I still need to be able to do something like '@attribute("target", T) void
func(string T)()', or maybe '@target(T) void func(string T)()' one way or
another. The template argument would be responsible for the appropriate
mangling in this case.
The reason is to be compatible with the DMD/LDC solutions, which would also
use template selection.f

The part I don't know is if T, a template argument to the function, can be used in the attribute declaration? This is critical.


On 27 May 2013 20:38, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 27 May 2013 11:18, Manu <turkeyman@gmail.com> wrote:
> > On 27 May 2013 19:01, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> >>
> >> On 27 May 2013 09:21, Manu <turkeyman@gmail.com> wrote:
> >> > Actually, I think the C counterpart is actually
> >> > __attribute__((__target__("targetstring"))), with bonus underscores ;)
> >> >
> >> >
> >> > On 27 May 2013 18:15, Manu <turkeyman@gmail.com> wrote:
> >> >>
> >> >> So we talked about this at DConf.
> >> >>
> >> >> Working on std.simd, I need to be able to change the target parameter
> >> >> on a
> >> >> per-function basis.
> >> >> GCC supports this via: __attribute__((target("sse2"))) for instance.
> >> >>
> >> >> I need the ability to set this from D, but the trick is, I need to be
> >> >> able
> >> >> to set the target string according to a template arg.
> >> >>
> >> >> Eg:
> >> >>   enum Targets { SSE2, SSE3 };
> >> >>   enum targets[] = [ "sse2", "sse3" ];
> >> >>
> >> >>   @attribute("target", targets[T]) // <- attribute needs to refer to
> >> >> the
> >> >> template arg T
> >> >>   void func(Targets T)();
> >> >>
> >> >>
> >>
> >> I'll turn on rudimentary support, as the backend takes care of pretty much all the work.  But I think this should work as UDAs work off CTFE with string manipulation.
> >>
> >>
> >> >>   {
> >> >>     // this way, it is possibly to produce dynamic selection of code
> >> >> paths
> >> >> optimised for different CPU features (a task which is usually very
> >> >> tedious
> >> >> in C/C++)
> >> >>     func!(Targets.SSE2)();
> >> >>   }
> >> >>
> >> >
> >>
> >> As a small experiment, I could turn on versioning for these functions...  However is only available for x86 targets.
> >>
> >> eg:
> >>
> >> void foo() @target("sse")    // mangled 'foo.sse'
> >> {
> >> }
> >>
> >> void foo() @target("mmx")   // mangled 'foo.mmx'
> >> {
> >> }
> >
> >
> > I'm confused, are you suggesting to handle these particular values
> > explicitly in gdc?
> > I was giving examples of the code I want to write (and work). I can
> handle
> > this in std.simd.
> > I don't think there's any reason to handle arch-specific cases like that
> in
> > gdc.
> >
> > Or rather, was the point you were trying to make here the possible
> support
> > of a @target() attribute (which affects the mangling), rather than
> > @attribute("target")?
>
> OK, if your confused, I won't do it then... :)
>
> --
> Iain Buclaw
>
> *(p < e ? p++ : p) = (c & 0x0f) + '0';
>

On 27 May 2013 11:47, Manu <turkeyman@gmail.com> wrote:
> By 'it', you mean supporting @target? Or handling specific targets + mangling?
>
> I still need to be able to do something like '@attribute("target", T) void
> func(string T)()', or maybe '@target(T) void func(string T)()' one way or
> another. The template argument would be responsible for the appropriate
> mangling in this case.
> The reason is to be compatible with the DMD/LDC solutions, which would also
> use template selection.f
>
> The part I don't know is if T, a template argument to the function, can be used in the attribute declaration? This is critical.
>
>

If it's a string constant, then answer should be yes.... can you pull gdc head and re-compile to test?

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

For MinGW? I've never successfully managed to build that bloody thing! ;)


On 27 May 2013 21:08, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 27 May 2013 11:47, Manu <turkeyman@gmail.com> wrote:
> > By 'it', you mean supporting @target? Or handling specific targets + mangling?
> >
> > I still need to be able to do something like '@attribute("target", T)
> void
> > func(string T)()', or maybe '@target(T) void func(string T)()' one way or
> > another. The template argument would be responsible for the appropriate
> > mangling in this case.
> > The reason is to be compatible with the DMD/LDC solutions, which would
> also
> > use template selection.f
> >
> > The part I don't know is if T, a template argument to the function, can
> be
> > used in the attribute declaration? This is critical.
> >
> >
>
> If it's a string constant, then answer should be yes.... can you pull gdc head and re-compile to test?
>
> --
> Iain Buclaw
>
> *(p < e ? p++ : p) = (c & 0x0f) + '0';
>

Well it is in...

https://github.com/D-Programming-GDC/GDC/commit/15907b95026d451f443b4b6d263c85e0524e517e


As for testing:
---
{
  @attribute("target", T)  void func(string T)() { }

  func!"sse.4.1";
}
---

Error: undefined identifier T.


Looks like the frontend rejects this - will find out whether this is a bug or intentional...


--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';



On 27 May 2013 12:17, Manu <turkeyman@gmail.com> wrote:
> For MinGW? I've never successfully managed to build that bloody thing! ;)
>
>
> On 27 May 2013 21:08, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>>
>> On 27 May 2013 11:47, Manu <turkeyman@gmail.com> wrote:
>> > By 'it', you mean supporting @target? Or handling specific targets + mangling?
>> >
>> > I still need to be able to do something like '@attribute("target", T)
>> > void
>> > func(string T)()', or maybe '@target(T) void func(string T)()' one way
>> > or
>> > another. The template argument would be responsible for the appropriate
>> > mangling in this case.
>> > The reason is to be compatible with the DMD/LDC solutions, which would
>> > also
>> > use template selection.f
>> >
>> > The part I don't know is if T, a template argument to the function, can
>> > be
>> > used in the attribute declaration? This is critical.
>> >
>> >
>>
>> If it's a string constant, then answer should be yes.... can you pull gdc head and re-compile to test?
>>
>> --
>> Iain Buclaw
>>
>> *(p < e ? p++ : p) = (c & 0x0f) + '0';
>
>

On 27 May 2013 21:40, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> Well it is in...
>
>
> https://github.com/D-Programming-GDC/GDC/commit/15907b95026d451f443b4b6d263c85e0524e517e
>
>
> As for testing:
> ---
> {
>   @attribute("target", T)  void func(string T)() { }
>
>   func!"sse.4.1";
> }
> ---
>
> Error: undefined identifier T.
>
>
> Looks like the frontend rejects this - will find out whether this is a bug or intentional...
>

Yep, I saw that coming a mile off! >_<
I can't imagine any good reason why it shouldn't be supported. Just that
nobody ever considered it in the context of UDA's.

On Monday, 27 May 2013 at 12:02:28 UTC, Manu wrote:
> On 27 May 2013 21:40, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>> Looks like the frontend rejects this - will find out whether this is a
>> bug or intentional...
>>
>
> Yep, I saw that coming a mile off! >_<
> I can't imagine any good reason why it shouldn't be supported. Just that
> nobody ever considered it in the context of UDA's.

Does it work if you spell out the template and put the attribute on the function? Might be good as a workaround for testing.

David