Skip to content

[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

Merged
merged 17 commits into from
Nov 20, 2023

Conversation

mdtoguchi
Copy link
Contributor

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.

…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.
@mdtoguchi
Copy link
Contributor Author

dependent on #10850

@mdtoguchi mdtoguchi temporarily deployed to WindowsCILock October 19, 2023 01:50 — with GitHub Actions Inactive
@mdtoguchi
Copy link
Contributor Author

Also dependent on #11034

@LU-JOHN
Copy link
Contributor

LU-JOHN commented Oct 25, 2023

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?

@mdtoguchi
Copy link
Contributor Author

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.

@LU-JOHN
Copy link
Contributor

LU-JOHN commented Oct 25, 2023

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?

@mdtoguchi
Copy link
Contributor Author

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.

@mdtoguchi mdtoguchi temporarily deployed to WindowsCILock October 26, 2023 01:21 — with GitHub Actions Inactive
@mdtoguchi mdtoguchi temporarily deployed to WindowsCILock October 26, 2023 19:45 — with GitHub Actions Inactive
Lu, John added 2 commits October 30, 2023 12:43
…ernels. Kernels provided by source (i.e. not a library). Splitting per-kernel.

Signed-off-by: Lu, John <[email protected]>
@LU-JOHN LU-JOHN temporarily deployed to WindowsCILock October 30, 2023 21:02 — with GitHub Actions Inactive
Copy link
Contributor

@hchilama hchilama left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mdtoguchi
Copy link
Contributor Author

@asudarsa, please take a look - thanks!

@mdtoguchi
Copy link
Contributor Author

@asudarsa, could you take another look? Thanks!

Copy link
Contributor

@asudarsa asudarsa left a 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

Copy link
Contributor

@LU-JOHN LU-JOHN left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mdtoguchi
Copy link
Contributor Author

@intel/llvm-gatekeepers, can this be merged?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants