[RFC PATCH] targetm.omp.device_kind_arch_isa and OpenMP declare variant kind/arch/isa handling

[Jakub Jelinek]

On Wed, Oct 30, 2019 at 02:12:30PM +0000, Szabolcs Nagy wrote:
> On 29/10/2019 17:15, Jakub Jelinek wrote:
> > +void f03 (void);
> > +#pragma omp declare variant (f03) match (device={kind(any),arch(x86_64),isa(avx512f,avx512bw)})
> > +void f04 (void);
> 
> 1) it's not clear from the omp spec what is the intended
> syntax for isa-name, arch-name and extension-name, but
> i expected strings in "".

Yes, it is indeed not clear, subject to ongoing discussions.
My reading of the spec was that all the *-name-list are comma
separated lists of identifiers, some others in the committee
want now (yesterday's discussions) string literals instead
when I and others pointed out that isa(core-avx512) can't be valid,
but strangely only for isa/arch/extension but not e.g. for
kind or vendor which would still take identifier lists etc.
My preference at this point would be probably to allow
in all vendor/kind/arch/isa/extension lists of either
identifiers or string literals, so for names which don't contain
characters invalid in identifiers users could choose what to write,
so both isa(avx512f,avx512bw) and isa("avx512f","avx512bw")
would be valid (and so would be isa(avx512f,"avx512bw")), obviously
for something that is not a valid identifier users wouldn't have a choice,
armv8.2-a+sve is not an identifier.

> what if an arch or isa name contains ',' ')' etc?
> 
> we were planing to use things like
> 
> isa("sve")
> arch("armv8.2-a+sve")
> extension("scalable")

That is subject to yet another ongoing discussion in the committee,
what shall be the meaning of isa and what shall be the meaning of arch,
I think we need something that will hold the GCC target or something similar
and something that holds the instruction sets for that target.
extension, given it is in the implementation trait set, is IMNSHO not meant
to hold device extensions, but rather software extensions or something
similar.
ARM is an OpenMP member, so if you want, you can participate too.
https://github.com/OpenMP/spec/issues/2028
is where I'm trying to track all the declare variant issues that need
clarification (plus in two examples tickets).

> 2) does f03 need to be declared before the declare variant
> pragma appears?

Yes.  For C++ the spec says that the actual function declaration
is determined by what would be called at the point of the pragma with
the given id-expression and arguments with types from the function
declaration on which the pragma is used, so it can involve ADL, needs to
deal with function overloading etc.

> for simd variants it means i need to declare the function
> with the right simd types and attributes.

For simd it is actually not finished yet, what needs to be done is that
given the declare simd clauses used as properties of the simd selector
the FEs use some target hook that will guide it how to transform
the parameters like targetm.simd_clone.compute_vecsize_and_simdlen
does and for C tries to just match the types against it and determine
through that the ABI and perhaps missing simd clauses like
notinbranch/inbranch, simdlen etc., for C++ actually for each possibility
will try to construct a call with such arguments and then compare the types.

I'd like to make non-simd working first though, for some cases it already
works and replacement is done in the gimplifier, but scoring needs to be
added, then some way to keep such info in the cgraph (will need to talk to
Honza) and after IPA perform another attempt to redirect.

	Jakub