[cfe-dev] Implementing OpenMP function variants

[John McCall via cfe-dev]

On 18 Dec 2019, at 15:25, Doerfert, Johannes wrote:
> On 12/18, John McCall wrote:
>> On 18 Dec 2019, at 15:02, Doerfert, Johannes wrote:
>>> On 12/18, John McCall wrote:
>>>> On 18 Dec 2019, at 14:25, Doerfert, Johannes wrote:
>>>>> On 12/18, John McCall wrote:
>>>>>> On 18 Dec 2019, at 11:16, Doerfert, Johannes wrote:
>>>>>>> Is there a good reason to make 5.1-type variants different from
>>>>>>> multi-versions (as we have them)? They do not depend on
>>>>>>> the lexical call
>>>>>>> context but only on the compilation parameters.
>>>>>>
>>>>>> Are multi-versions yet another feature?  Do they interact
>>>>>> with this one?
>>>>>
>>>>> In 5.1, `begin/end declare variant` multi-version a function
>>>>> basically
>>>>> the same way as `__attribute__((target(...)))` does. The
>>>>> condition can
>>>>> be more than only a target though. (I mispoke earlier, it can
>>>>> include
>>>>> call site context information). So we have multiple versions of a
>>>>> function, let's say "sin", and depending on the compilation target,
>>>>> e.g., are we compiling for nvptx or not, ans call site context,
>>>>> e.g.,
>>>>> are we syntacitally inside a parallel region, we pick on of
>>>>> them. The
>>>>> prototype for this reuses almost all of the multi-version code that
>>>>> enables the target attribute as it seemed to be the natural fit.
>>>>
>>>> I see.  And that’s still totally statically selected at use time,
>>>> right?
>>>
>>> Yes, as of OpenMP TR8 (Nov this year). But (to me) it is fairly certain
>>> we'll also get an dynamic dispatch version too, maybe even this year
>>> (for
>>> OpenMP 5.1).
>>
>> A dynamic version of `__attribute__((target))`, or of variants, or both?
>
> A dynamic version of variants, potentially both kinds:
>  The 5.0 declare variant (=different names for base and variant
>  function).
>  The 5.1 begin/end declare variant (=same name for base and variant
>  function).
>
> I maybe was a bit confusing earlier:
>  We don't actually have __attribute__((target)) but begin/end declare
>  variant is very similar in the behavior right now.

Don’t you have context-specific variants?  How would you expect dynamic
dispatch to work?

Anyway, if dynamic dispatch is on the table, then this question gets
very interesting.

As a general matter, I think the AST should represent the formal semantics
of the program.  Absent dynamic dispatch, the semantics are that a use is
resolved to a particular function.  And Sema generally needs to know
what declaration(s) are actually being used — we may need to diagnose
something about the use (e.g. deprecation or unavailability), or we may
just need to mark other declarations as used transitively, instantiate
templates, and so on.  So resolving the lookup down to the underlying
variant but recording the lookup/delegation structure via the FoundDecl
makes sense to me.

But if the semantics are potentially dynamic then that starts coming
apart a little because it’s very important whether a reference is
semantically to the whole variant set or specifically to the non-variant
base declaration.  We have some limited ability to represent differences
like this with GlobalDecl; however, this is a much more substantial
difference than e.g. constructor variants because using the whole variant
set means using all of the declarations in it.  If we decide that
GlobalDecl is the right abstraction for this, we may have to push it
through a bunch of different places.  Alternatively, we might want to
introduce a new kind of declaration that represents a variant set.

John.