Skip to content
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

[SYCL][E2E] Add functionality to split build and run of e2e tests #16016

Merged
merged 24 commits into from
Nov 22, 2024

Conversation

ayylol
Copy link
Contributor

@ayylol ayylol commented Nov 7, 2024

Adds functionality to split the compilation and execution of e2e tests across separate machines.

This functionality is enabled via the test-mode lit parameter. By default this is set to full and tests are built and ran on the same system, just like before. setting test-mode to either run-only or build-only enables the test splitting.

Two new lit features have been added: run-mode which is enabled when either in run-only or full testing mode, and build-and-run-mode which is only enabled when in full testing mode.

When in build-only mode all tests that can be built on the system will be built. When running a lit test in this mode two key things change:

  • All RUN: lines will be executed unless they contain %{run}, %{run-unfiltered-devices} or %if run-mode.
  • Unsupported and requires statements are ignored. Currently the only way to mark tests as unsupported in build only mode is to include build-and-run-mode in a requires statement, or use UNSUPPORTED: true.

When in run-only mode tests are not built, they are only executed. Deciding whether a test is supported in this mode works the same as in full mode. To only execute the tests we ignore all lit RUN: lines unless they contain %{run}, %{run-unfiltered-devices} or %if run-mode. Since we do not build the tests in this mode, for any test to pass we must have ran the tests in either build-only or full modes.

Some notes/current limitations:

  • Currently only the spir64 triple is supported for the build only mode.
  • If a test is able to build, but fails during running we need to mark it as XFAILS: run-mode so that it does not XPASS when in build-only mode.
  • The build-only mode can be ran manually on CI with the SYCL E2E action, selecting the "Linux, build" runner, and adding --param test-mode=build-only to LIT_OPTS. This pr does not have the needed CI changes to be able to use the run only mode.

@ayylol
Copy link
Contributor Author

ayylol commented Nov 7, 2024

@uditagarwal97 @sarnex @aelovikov-intel

Closed #15728 and reopened in this pr so that it is not a sycl-devops-pr and runs unnecessary checks.

Going to leave this marked as draft until you guys review and are ok with the changes in format.py and lit.cfg.py, then mark as open so that it pings the tests owners after

https://github.com/intel/llvm/actions/runs/11725963631 is the latest dry-run of build only

@sarnex
Copy link
Contributor

sarnex commented Nov 12, 2024

@ayylol Sorry just to double check, is this ready for review from us CI people or is it still in progress? Thx.

@ayylol
Copy link
Contributor Author

ayylol commented Nov 12, 2024

@ayylol Sorry just to double check, is this ready for review from us CI people or is it still in progress? Thx.

@sarnex Yep, its ready for review. Im just leaving it as draft in case any of the changes to the underlying logic from addressing reviews leads to more/different test changes.

Copy link
Contributor

@sarnex sarnex left a comment

Choose a reason for hiding this comment

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

some basic comments

@@ -1,5 +1,6 @@
// UNSUPPORTED: windows
// REQUIRES: cuda || hip
// REQUIRES: unsplit-mode
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: we might want something more descriptive here, if possible UNSUPPORTED: split-test-build-and-run or something like that

Copy link
Contributor Author

@ayylol ayylol Nov 12, 2024

Choose a reason for hiding this comment

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

Will address this comment last to leave open to bike-shedding. Would something like unsplit-test-mode work? or unsplit-testing, should the other features (build-mode, run-mode) follow suit? or are they clear enough.

I don't think i'd want to put the word "split" in this particular feature, since it is exactly what it isn't.

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah of course i dont want to start bikeshedding, REQUIRES: unsplit-test-mode is fine with me

Copy link
Contributor

Choose a reason for hiding this comment

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

Won't it be clearer to have something like only-build-test, only-run-test, build-and-run-test instead of build-mode, run-mode, and unsplit-test-mode?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Won't it be clearer to have something like only-build-test, only-run-test, build-and-run-test instead of build-mode, run-mode, and unsplit-test-mode?

The run-mode feature is useful because it allows us to have common behaviour between the run-only and unsplit modes, if we didnt have it we would have to mark tests that xfail at run-time as both XFAIL on only-run-test and build-and-run-test.

The build-mode feature I could not think of a valid use for, since if we have an xfail at build time we would always also want to mark it as an xfail at run-time since we wouldn't have an executable, also a test in the e2e folder that uses REQUIRES: build-mode seems a bit suspicious.

I added something like build-only/run-only/unsplit as a variable within the python scripts, but not as a feature since their usefulness in that context is unclear to me. Rather I'm using them to clean up if statements in the python scripts where we want to check what split-mode we are in.

@@ -11,7 +11,7 @@
// RUN: %{build} -o %t.out
// RUN: %{run} %t.out

// XFAIL:*
// XFAIL: run-mode
Copy link
Contributor

Choose a reason for hiding this comment

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

sorry if i asked this before but i wonder if we can implement this inside the python scripts instead of requiring test changes

Copy link
Contributor Author

Choose a reason for hiding this comment

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

These changes are to differentiate between tests that fail when compiling vs tests that fail when running. These tests originally are able to build so marking as XFAIL: run-mode makes sure these tests arent reported as XPASS when building only.

Copy link
Contributor

Choose a reason for hiding this comment

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

I want (very strongly) to start with explicit tests markup first before we introduce any heuristics in the lit logic, especially if that's really heuristics and not some bullet-proof correct logic.

Copy link
Contributor

Choose a reason for hiding this comment

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

i guess im just worried this feature will slow down/confuse developers writing tests, im willing to proceed with this as-is and see what happens, but we should be ready to revert/fix the problem fast if some issue comes up

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i guess im just worried this feature will slow down/confuse developers writing tests, im willing to proceed with this as-is and see what happens, but we should be ready to revert/fix the problem fast if some issue comes up

For now since there is no automatic running on CI enabled, we'll just have to monitor the failures manually.

However once this is integrated into the post/pre commit I think it should be pretty straightforward to figure out the appropriate action given the ci's behaviour:

  • If we see that a test passes the build stage but fails the run stage we have a runfail, and if this is expected we would mark it as XFAIL/UNSUPPORTED on run-mode.
  • If it fails on both the build and run stage then we have a compfail and we would mark as XFAIL/UNSUPPORTED * (Or we could mark as XFAIL for a feature that is non-device-specific, like linux).

(backend, _) = sycl_device.split(":")
triples.add(get_triple(test, backend))
if "run-mode" not in test.config.available_features:
if "unsplit-mode" in test.requires or "TEMPORARY_DISABLED" in test.requires:
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe im reading the lit.cfg.py change wrong but isn't run-mode && !unsplit-mode impossible? If it's intended to be an error check I'm not sure how the user could ever configure lit to be in that state

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This bit is for build-only mode, so that only the tests that are marked as REQUIRES: unsplit-mode or REQUIRES: TEMPORARY_DISABLED are reported as unsupported.

I guess it might be useful if I added a feature for run-only and build-only to avoid confusion in if statements like this

Copy link
Contributor

@sarnex sarnex Nov 12, 2024

Choose a reason for hiding this comment

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

ah sorry, i missed that we were checking the test requires,thx

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added the variable test.config.split_mode to hopefully make these types of if statements less confusing to read. (replaced "run-mode" not in available_features to split_mode == "build-only" )

Copy link
Contributor

@uditagarwal97 uditagarwal97 left a comment

Choose a reason for hiding this comment

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

lit.cfg.py and format.py changes LGTM too. Just one minor comment.

sycl/test-e2e/lit.cfg.py Outdated Show resolved Hide resolved
@ayylol
Copy link
Contributor Author

ayylol commented Nov 15, 2024

Closed the following PRs to include their changes in this PR: #15960, #15950, #15891, #15787, #15789

Doing this all in one pr so that all the changes needed to cleanly run the build-only mode on ci are included in one single commit.

@ayylol ayylol marked this pull request as ready for review November 15, 2024 19:51
@ayylol ayylol requested review from a team as code owners November 15, 2024 19:51
Copy link
Contributor

@YuriPlyakhin YuriPlyakhin left a comment

Choose a reason for hiding this comment

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

Joint Matrix changes LGTM

@againull
Copy link
Contributor

@intel/bindless-images-reviewers @intel/syclcompat-lib-reviewers @intel/unified-runtime-reviewers Friendly ping.

@againull againull merged commit f279a8a into sycl Nov 22, 2024
14 checks passed
@ayylol ayylol deleted the e2e-split branch November 22, 2024 15:06
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.

9 participants