-
Notifications
You must be signed in to change notification settings - Fork 743
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
Conversation
@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 |
but are marked as XFAIL in different ways
Added a run-line to one test as well
@ayylol Sorry just to double check, is this ready for review from us CI people or is it still in progress? Thx. |
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.
some basic comments
@@ -1,5 +1,6 @@ | |||
// UNSUPPORTED: windows | |||
// REQUIRES: cuda || hip | |||
// REQUIRES: unsplit-mode |
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.
nit: we might want something more descriptive here, if possible UNSUPPORTED: split-test-build-and-run
or something like that
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.
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.
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.
yeah of course i dont want to start bikeshedding, REQUIRES: unsplit-test-mode
is fine with me
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.
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
?
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.
Won't it be clearer to have something like
only-build-test
,only-run-test
,build-and-run-test
instead ofbuild-mode
,run-mode
, andunsplit-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.
sycl/test-e2e/DeviceArchitecture/device_architecture_comparison_on_device_aot.cpp
Outdated
Show resolved
Hide resolved
@@ -11,7 +11,7 @@ | |||
// RUN: %{build} -o %t.out | |||
// RUN: %{run} %t.out | |||
|
|||
// XFAIL:* | |||
// XFAIL: run-mode |
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.
sorry if i asked this before but i wonder if we can implement this inside the python scripts instead of requiring test changes
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.
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.
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.
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.
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.
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
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.
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
).
sycl/test-e2e/format.py
Outdated
(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: |
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.
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
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.
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
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.
ah sorry, i missed that we were checking the test requires,thx
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.
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"
)
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.
lit.cfg.py
and format.py
changes LGTM too. Just one minor comment.
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.
Joint Matrix changes LGTM
@intel/bindless-images-reviewers @intel/syclcompat-lib-reviewers @intel/unified-runtime-reviewers Friendly ping. |
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 tofull
and tests are built and ran on the same system, just like before. settingtest-mode
to eitherrun-only
orbuild-only
enables the test splitting.Two new lit features have been added:
run-mode
which is enabled when either inrun-only
orfull
testing mode, andbuild-and-run-mode
which is only enabled when infull
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:RUN:
lines will be executed unless they contain%{run}
,%{run-unfiltered-devices}
or%if run-mode
.build-and-run-mode
in a requires statement, or useUNSUPPORTED: 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 infull
mode. To only execute the tests we ignore all litRUN:
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 eitherbuild-only
orfull
modes.Some notes/current limitations:
XFAILS: run-mode
so that it does notXPASS
when in build-only mode.SYCL E2E
action, selecting the "Linux, build" runner, and adding--param test-mode=build-only
toLIT_OPTS
. This pr does not have the needed CI changes to be able to use the run only mode.