Skip to content

[SYCL][E2E] Implement support for REQUIRES in build-only mode #16716

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

Closed
wants to merge 3 commits into from

Conversation

Maetveis
Copy link
Contributor

In general we cannot separate
build only features from features that only have an effect during
execution. Consider a REQUIRES expression containing a mix of runtime
and build time features. If the expression evaluates to false in
build-only we would have to solve a Satisfiability (SAT) problem to
check if it only failed due to missing run-time features.
The below design is motivated by this and the fact that current
REQUIRES, UNSUPPORTED and XFAIL lines assume that both run-time
(per-device) and build only features are available.

Add a new directive ENABLE_RUN_REQUIRES: true, which, if present, changes
the evaluation of REQUIRES, UNSUPPORTED and XFAIL directives to
only consider device-agnostic features. This allows them to be correctly
evaluated during test-mode="build-only" too. To express per-device
(run-time) requirements the directives RUN_REQUIRES, RUN_UNSUPPORTED
and RUN_XFAIL can be added.

The config and directive takes a boolean value to allow gradual adoption
of the feature.

This commit does not yet change the documentation of the test-mode
parameter in README.md, if this looks like a good direction I can do
that too with help on the wording.

I also have not figured out how this should interact with #16306 yet, @ayylol input welcome.

I personally made these changes because I encountered this limitation during personal testing with build-only mode in Intel internal repositories, hopefully nobody else was actively working on this.

Currently if a test contains a malformed directive, the following
exception is raised along with the original parsing error:
```plaintext
Exception during script execution:
(original error)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "llvm/llvm/utils/lit/lit/worker.py", line 76, in _execute_test_handle_errors
    result = test.config.test_format.execute(test, lit_config)
  File "llvm/sycl/test-e2e/format.py", line 232, in execute
    script = self.parseTestScript(test)
  File "llvm/sycl/test-e2e/format.py", line 105, in parseTestScript
    return lit.Test.Result(Test.UNRESOLVED, str(e))
NameError: name 'Test' is not defined
```
The test ends up as UNRESOLVED either way, but fixing it is easy and
improves the error message greatly.
These only apply when the test is going to be running i.e. only
in `test_mode = "full"`` or `test_mode == "run-only"`. I want to
use the unprefixed names in a follow up commit.
In general we cannot separate
build only features from features that only have an effect during
execution. Consider a `REQUIRES` expression containing a mix of runtime
and build time features. If the expression evaluates to false in
build-only we would have to solve a Satisfiability (SAT) problem to
check if it only failed due to missing run-time features.
The below design is motivated by this and the fact that current
`REQUIRES`, `UNSUPPORTED` and `XFAIL` lines assume that both run-time
(per-device) and build only features are available.

Add a new directive `ENABLE_RUN_REQUIRES: true`, which, if present, changes
the evaluation of `REQUIRES`, `UNSUPPORTED` and `XFAIL` directives to
only consider device-agnostic features. This allows them to be correctly
evaluated during `test-mode="build-only"` too. To express per-device
(run-time) requirements the directives `RUN_REQUIRES`, `RUN_UNSUPPORTED`
and `RUN_XFAIL` can be added.

This commit does not yet change the documentation of the `test-mode`
parameter in README.md, if this looks like a good direction I can do
that too with help on the wording.
@Maetveis Maetveis requested a review from a team as a code owner January 21, 2025 15:51
@ayylol
Copy link
Contributor

ayylol commented Jan 21, 2025

I personally made these changes because I encountered this limitation during personal testing with build-only mode in Intel internal repositories, hopefully nobody else was actively working on this.

Hey, I was working on something to address this in #16637, wonder if that may work for your use-case.

@Maetveis
Copy link
Contributor Author

Hey, I was working on something to address this in #16637, wonder if that may work for your use-case.

I think it would, though I'm not sure the approach that is taken there is sound, I left comments. I feel like you're approaching the SAT solver territory, but I might be wrong.

@aelovikov-intel
Copy link
Contributor

I think @ayylol 's approach will work good enough and I want to explore that direction first. @Maetveis do you mind turning this PR into a draft state for the time being? We can return to it if David's approach fails.

@Maetveis Maetveis marked this pull request as draft January 21, 2025 18:02
@Maetveis Maetveis closed this Jan 31, 2025
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.

3 participants