-
Notifications
You must be signed in to change notification settings - Fork 788
[SYCL][E2E] Reduce number of FileCheck
uses
#18848
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] Reduce number of FileCheck
uses
#18848
Conversation
LIT is perfectly capable of checking the exit code and there is no need to deal with any extra output parsing and I/O.
// RUN: env SYCL_PI_LEVEL_ZERO_TRACK_INDIRECT_ACCESS_MEMORY=1 %{run} %t.out 2>&1 | FileCheck %s | ||
// | ||
// CHECK: pass | ||
// RUN: env SYCL_PI_LEVEL_ZERO_TRACK_INDIRECT_ACCESS_MEMORY=1 %{run} %t.out 2>&1 |
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 am not sure if this is the right PR to address this, but isn't SYCL_PI
deprecated? Shouldn't this be SYCL_UR
instead?
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.
All SYCL_PI variables still work, and there are no plans to deprecate them (at least in the L0v1 adapter).
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.
@pbalcer but do we have SYCL_UR equivalents? If so, I'd say we should go for SYCL_UR ones.
@@ -87,12 +87,11 @@ int main(int argc, char **argv) { | |||
passed = false; | |||
} | |||
} | |||
std::cout << (passed ? "passed\n" : "FAILED\n"); | |||
if (!passed) |
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.
In the same vein, why do we need to emit "FAILED"? Can we clean this up 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.
I can submit a follow-up PR for that: I'm less concerned about the negative path, since it is not expected to be triggered often.
LIT is perfectly capable of checking the exit code and there is no need to deal with any extra output parsing and I/O.