[Driver][SYCL] Address issue with code splitting and FPGA Archives #15794
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
When enabling device code splitting with FPGA archive generation (-fsycl-link) the resulting device images were not packed correctly. We were archiving the resulting -batch wrapped image, which in turn would not be extracted properly when being consumed. To address this, update how the device images are created for insertion into the archive to be individual split binaries as opposed to using the wrapper -batch behavior. This is performed for both the early and image type archives.
mdtoguchi
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mdtoguchi
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mdtoguchi
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mdtoguchi
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
sergey-semenov
approved these changes
Oct 23, 2024
sarnex
approved these changes
Oct 23, 2024
mdtoguchi
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mdtoguchi
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
|
@intel/dpcpp-clang-driver-reviewers - ping for review |
asudarsa
reviewed
Oct 23, 2024
asudarsa
reviewed
Oct 23, 2024
| @@ -10263,8 +10263,18 @@ void OffloadWrapper::ConstructJob(Compilation &C, const JobAction &JA, | |||
| const InputInfo &I = Inputs[0]; | |||
| assert(I.isFilename() && "Invalid input."); | |||
|
|
|||
| if (I.getType() == types::TY_Tempfiletable || | |||
| I.getType() == types::TY_Tempfilelist || IsEmbeddedIR) | |||
| // TODO: The embedded compilation step after the wrapping step restricts | |||
There was a problem hiding this comment.
Why is this a TODO? Is this not more of a restriction?
There was a problem hiding this comment.
It is a restriction - but in my opinion it would be best to pull the compile step out of the wrapping step which provides a cleaner picture of the toolchain. We shouldn't expect the wrapping step to do the compilation too (it isn't embedded for OpenMP)
asudarsa
reviewed
Oct 23, 2024
asudarsa
approved these changes
Oct 23, 2024
mdtoguchi
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
srividya-sundaram
approved these changes
Oct 23, 2024
mdtoguchi
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mdtoguchi
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mdtoguchi
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
|
@intel/llvm-gatekeepers, this is ready for merge - thanks! |
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.
When enabling device code splitting with FPGA archive generation (-fsycl-link) the resulting device images were not packed correctly. We were archiving the resulting -batch wrapped image, which in turn would not be extracted properly when being consumed.
To address this, update how the device images are created for insertion into the archive to be individual split binaries as opposed to using the wrapper -batch behavior. This is performed for both the early and image type archives.