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