> On Nov 21, 2019, at 4:09 PM, Richard Sandiford <richard.sandif...@arm.com>
> wrote:
>
> This probably isn't helpful, sorry, but the fact that the second point
> is a (reasonable) area of debate IMO shows the problems with doing
> the first point. If we go for (1) but not (2), everyone will need
> to specify the four initial parameters. But we'd have to allow (2)
> to be optional if we added it later. We might in future also want other
> parameters, e.g. for uniform arguments, by-value vs. by-ref, etc.
>
> Maybe we could have key-value pairs?
>
> __attribute__((__simd__("simdlen", 2, "simdabi", "n")))
>
> This would also allow linear parameters to be specified like this:
>
> __attribute__((__simd__("simdlen", 2, "linear", 2, "linear", 3, ...)))
>
> The current attribute syntax doesn't allow { 1, 2 } as an attribute
> parameter, and adding it now wouldn't be backward compatible (since
> older toolchains should be free to ignore this).
>
If we cannot do { 1, 2 }, I’d rather have the following syntax
__attribute__((__simd__(“name”, [not]inbranch, simdlen(2), simdabi(“n”),
linear(ref(1)[:step], uval(2)[:step],…), linear_pos(ref(1)[:pos],
uval(2)[:pos],…), uniform(4,5…), align(8,9[:val]))))
With no_linear, no_linear_pos, no_uniform and no_align to be specified when not
used, and step/pos/val with the same default values as in the OpenMP Standard
when not specified.
With this, all that we need to implement (for now) for sincos is (just use
no_linear for sin/exp/log...)
__attribute__((__simd__(“name”, [not]inbranch, simdlen(2), simdabi(“n”),
linear(1,2), no_linear_pos, no_uniform, no_align))))
(Btw, happy for all those values to be strings if we cannot use identifiers)
__attribute__((__simd__(“name”, "[not]inbranch", "simdlen(2)", "simdabi(n)",
"linear(1,2)", “no_linear_pos", “no_uniform", “no_align"))))
> I realise the key-value approach makes things more complicated though.
> I guess we're in danger of reinventing omp declare variant that way. :-)
>
Yep :)
How much this is gonna be useful beyond “flat vectorization” and sincos
vectorization is debatable (users can use OpenMP for this...), but at least we
would have some ground for expanding it if / when needed, with backward
compatibility in mind.
> I'm in two minds about whether we should expose the simdabi as the
> mangling character. On the one hand it's simple, on the other it seems
> a bit too low-level for something like this. I think we'd need to check
> whether the parameter is valid anyway, so maybe we should have some more
> user-friendly mnemonics?
>
No preference here, if not for the fact that the mangling character is already
encoded in the specs, so there is no space for interpretation: all we need to
do is to refer to the Vector Function ABIs.
Thanks!
Francesco
