[SYCL] Annotate virtual calls in device IR

[AlexeySachkov]

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.

[AlexeySachkov]

The only failed test is:

Failed Tests (1):
  Clang :: Driver/sycl-offload-new-driver.c

And it is unrelated to this PR, it was addressed in #14051.

@intel/dpcpp-cfe-reviewers, could you please take a look?

[AlexeySachkov]

Tagging @gmlueck here explicitly to review the added test case to check if our virtual calls detection is good enough in context of KhronosGroup/SYCL-Docs#565 and potential SYCL spec changes.

[gmlueck]

Tagging @gmlueck here explicitly to review the added test case to check if our virtual calls detection is good enough in context of KhronosGroup/SYCL-Docs#565 and potential SYCL spec changes.

The test cases look good. I agree that the two cases labeled "Strictly speaking, this is a virtual function call, but clang emits it as a direct call" are a little weird, but it seems like both clang and gcc emit these as direct calls. Therefore, I think it is OK if we treat this as a direct call for diagnostic purposes.