-
Notifications
You must be signed in to change notification settings - Fork 787
[Driver][SYCL][FPGA] Improve AOCX archive behaviors with -fsycl-link=image #11592
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
Conversation
…image Use of -fsycl-link=image allows for FPGA users to create a full device binary and store it in an archive to be used later. This archive can then be picked up and linked in. The information stored in the archive was not sufficient, causing the device binary to not be 'visible' when linked in. Improve the situation here by saving all of the information provided by the wrapping step (including symbols) in the archive, but also be sure that this entire final binary is saved as it would be if we were performing a full E2E compilation. To accomodate the ability to pass around the needed symbols and properties that are used when wrapping the final binaries for any AOCR or AOCX type archives, update the way this information is passed around. Multiple binaries are added to the archive, including the full wrapped .bc file that is gathered and passed along to any subsequent wrapping sequence that occurs.
dependent on #10850 |
Also dependent on #11034 |
When we generate a new wrapped bc file with --sym-prop-bc-files, it is important that the order of the images provided through --sym-prop-bc-files matches the order of the images that is provided through the table. Otherwise the symbols and properties will be applied to mismatched images. Do the testcases check this? Do we have E2E tests for this new functionality? |
We should be able to test this via E2E with emulation. I don't think we have anything in place that performs AOCX and AOCR behaviors on our side. |
Will E2E tests be added to this PR or will they be done separately? |
I think I can add here, add to the tests-e2e area. |
…case fails. Signed-off-by: Lu, John <[email protected]>
…ernels. Kernels provided by source (i.e. not a library). Splitting per-kernel. Signed-off-by: Lu, John <[email protected]>
Signed-off-by: Lu, John <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@asudarsa, please take a look - thanks! |
@asudarsa, could you take another look? Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall changes look good to me. Minor nits. @LU-JOHN will need to approve as well.
Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@intel/llvm-gatekeepers, can this be merged? |
Use of -fsycl-link=image allows for FPGA users to create a full device binary and store it in an archive to be used later. This archive can then be picked up and linked in. The information stored in the archive was not sufficient, causing the device binary to not be 'visible' when linked in.
Improve the situation here by saving all of the information provided by the wrapping step (including symbols) in the archive, but also be sure that this entire final binary is saved as it would be if we were performing a full E2E compilation.
To accomodate the ability to pass around the needed symbols and properties that are used when wrapping the final binaries for any AOCR or AOCX type archives, update the way this information is passed around. Multiple binaries are added to the archive, including the full wrapped .bc file that is gathered and passed along to any subsequent wrapping sequence that occurs.