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';