[SYCL] Always do internalization in sycl-post-link #14976
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We already had `Internalize` pass being launched as part of a module cleanup phase in `sycl-post-link`, but it was only invoked when shared libraries/dynamic linking is enabled. However, there are other features that need this internalization and one (and the only, at least for now) is virtual functions. When virtual functions are used in a program it could be necessary to dynamically link several device images containing SYCL kernels together. The problem with that is that there are ITT instrumentation functions added to modules that have external linkage - they cause multiple definitions error when we try to link two kernels together, because both of them are instrumented. This problem is solved by running `Internalize` pass uncoditionally, but the criteria of what we can internalize depends on whether we enable shared libraries/dynamic linking support: - in regular flow, we can internalize any symbol that is not considered to be an entry point, because all device images are self-contained and there are no dependencies between them. - when dynamic linking is enabled, we should not internalize functions that can be imported/exported, even if they are not considered as module entry points. Tests were updated where necessary to expect or ignore linkage changes of some functions. InvokeSIMD pass had to be updated: ESIMD is handled through two-level device code split, meaning two cleanup phases where each of them could mistakenly drop some compiler-generated functions unless they are properly marked in LLVM IR.
AlexeySachkov
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
AlexeySachkov
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
AlexeySachkov
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
…ys-run-internalize
|
Looks like the E2E test failures are related. I'll take a look once those are fixed :) |
The problem is that I can't reproduce them locally :) |
|
I'll try quickly. |
LU-JOHN
reviewed
Aug 7, 2024
We debugged this offline, turned out that we incorrectly call |
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
sarnex
approved these changes
Aug 8, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We already had
Internalizepass being launched as part of a module cleanup phase insycl-post-link, but it was only invoked when shared libraries/dynamic linking is enabled.However, there are other features that need this internalization and one (and the only, at least for now) is virtual functions. When virtual functions are used in a program it could be necessary to dynamically link several device images containing SYCL kernels together.
The problem with that is that there are ITT instrumentation functions added to modules that have external linkage - they cause multiple definitions error when we try to link two kernels together, because both of them are instrumented.
This problem is solved by running
Internalizepass uncoditionally, but the criteria of what we can internalize depends on whether we enable shared libraries/dynamic linking support:Tests were updated where necessary to expect or ignore linkage changes of some functions. InvokeSIMD pass had to be updated: ESIMD is handled through two-level device code split, meaning two cleanup phases where each of them could mistakenly drop some compiler-generated functions unless they are properly marked in LLVM IR.