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 <ibuc...@ubuntu.com> wrote:
> On 27 May 2013 11:18, Manu <turkey...@gmail.com> wrote:
> > On 27 May 2013 19:01, Iain Buclaw <ibuc...@ubuntu.com> wrote:
> >>
> >> On 27 May 2013 09:21, Manu <turkey...@gmail.com> wrote:
> >> > Actually, I think the C counterpart is actually
> >> > __attribute__((__target__("targetstring"))), with bonus underscores ;)
> >> >
> >> >
> >> > On 27 May 2013 18:15, Manu <turkey...@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';
>
