-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is restriction on calling virtual member functions from device functions too strict? #565
Comments
I think this is the case that expr.call.2 refers to:
Yes, I agree. I think this proposed change makes sense. We will need to update the error checking in DPC++, though, because we currently diagnose both cases as an error. |
This commit is a part of virtual functions extension implementation that is proposed in #10540. As part of the feature, we would like to achieve both: - allow virtual function calls from SYCL kernels that are submitted with the right properties as described in the language extension specification - disallow virtual function calls from SYCL kernels that do not use any (or the right) properties to conform with the core SYCL 2020 specification Implementing such diagnostics will require call graph traversal to understand the origin of the call and that is not what's easy to do in FE. Therefore, the implementation design for virtual functions proposes that such diagnostic is offloaded to a pass. The draft of the analysis pass implementation can be seen in #14141 This commit is a preparations for it: it introduces an attribute to all virtual function calls in device code so they can be easily detected and not confused with plain function pointer calls (for which we don't have a language specification and therefore well-defined behavior yet). Note that the new approach will relax virtual function call diagnostics, because it will allow non-virtual calls to virtual functions to be performed from kernels. This is in line with discussion in KhronosGroup/SYCL-Docs#565 about relaxing current SYCL 2020 restrictions about virtual functions.
5.4. Language restrictions for device functions lists the following restriction (emphasis mine):
As I read this, no call to a virtual member function is allowed, even if the call is in fact direct, i.e. it does not involve virtual call mechanism. There are a few situations where the latter could occur:
From class.virtual.16:
Also, expr.call.2 (emphasis mine) suggests that there are cases when a call to a virtual member function is not considered to be a virtual call:
I.e. even if a selected function is virtual, but the class member access expression is in a certain form, the call is not considered to be a virtual call, but instead it is just a direct call to the said function. I'm properly lost in all those
id-expression
,qualified-id
and other terms from the C++ draft spec, but my understanding is that there is no virtual call mechanism involved in an example below:If my reading of both specs is correct, then we should update the restriction in the SYCL spec to say something like this (emphasis to highlight the diff):
I.e. we only disallow cases where virtual call mechanism is involved, but we allow direct (i.e. non-virtual) calls to functions that are defined as virtual.
The text was updated successfully, but these errors were encountered: