[cfe-dev] Implementing OpenMP function variants

[John McCall via cfe-dev]

On 18 Dec 2019, at 16:07, Doerfert, Johannes wrote:
> On 12/18, John McCall wrote:
>> 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?
>
> I'm not sure I understand your question but I expect us to generate an
> if-cascade in the most generic case.

Oh, so spell it out at the use site?  Yes, that makes sense; I don’t know
why I didn’t consider that.

>> 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.
>
> Sounds good. Thanks.
>
>
>> 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.
>
> I would prefer we table this discussion until after the January OpenMP
> standards meeting. I'll probably look into prototyping what we will
> define as preliminary semantics there.

WFM.

John.