[cfe-dev] Implementing OpenMP function variants

[Doerfert, Johannes via cfe-dev]

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.


> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20191218/ede9b074/attachment.sig>