Skip to content

calls-indirectly attribute propagation doesn't always happen as necessary #15071

@AlexeySachkov

Description

@AlexeySachkov

Describe the bug

sycl/test-e2e/VirtualFunctions/multiple-translation-units/separate-vf-defs-and-call.cpp and sycl/test-e2e/VirtualFunctions/multiple-translation-units/separate-vf-defs.cpp added by #15067 fail with unresolved symbols error, because we don't link necessary kernels together due to lack of information to do so.

To reproduce

That's an in-tree e2e test, it should be clear how to reproduce it.

Environment

  • OS: Linux
  • Target device and vendor: should not be device-dependent, but I tested it on PVC
  • DPC++ version: recent intel/llvm
  • Dependencies version: doesn't matter here

Additional context

When virtual functions are used, all kernels that use the same list of virtual functions should be linked together. We determine that a device image (and its kernels) use virtual functions if they are annotated by corresponding attributes coming from compile-time properties set by users.

However, for kernels that only construct objects with virtual functions, but don't do any virtual function calls we do not require any properties. Instead, we auto-infer them based on which virtual functions were referenced by a kernel through a reference to vtables.

This propagation step is currently happening during translation unit compilations step and that is too early, because if virtual functions are defined in a separate translation unit, then their declarations won't have necessary attributes and therefore won't be propagated.

One solution here is to move this propagation step into sycl-post-link so that we see all the IR and have all function definitions. However, it won't help if virtual functions are involved, i.e. if a virtual function is defined in a shared library.

Perhaps the first step that should be taken here is to investigate why don't we have indirectly-callable attribute attached to virtual function declarations, because if we fix that - then even shared libraries case will be supported without changes to the propagation pass.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions