[enhancement] XLS proc jit should detect at least trivial livelock conditions #1592
Labels
enhancement
New feature or request
Comments
copybara-service bot
pushed a commit
that referenced
this issue
Sep 5, 2024
Running dslx_tests though the ir jit allows much longer running tests to be run at the cost of somewhat significant (~1sec/test) startup time. Currently all tests in a file must be run with a single evaluator. The 'compare' dslx_test_args functionality is not available when using evaluators other than 'dslx-interpreter' since it directly relies on DSLX interpreter behaviors for its implementation. The evaluator option has no effect on quick_checks at this time. Bug: #1592 Bug: #1573 PiperOrigin-RevId: 671555663
|
Without solving the halting problem, one relatively easy case to catch would be: no data sent on channels, all procs blocked or iterating without changing state. |
|
yeah that's basically what I'm thinking of. Issue is that right now we don't really keep track of the old state for anything. Doing any sort of detection when values are actually being passed along channels is much more difficult. And of course full livelock detection is halting problem. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What's hard to do? (limit 100 words)
If you run a jit until blocked we have deadlock detection but we do not have livelock detection of any kind. Even trivial livelocks like an empty proc will make the 'until-blocked' useless.
Current best alternative workaround (limit 100 words)
Perform DFE to remove empty procs before running the proc jit and avoid other livelock patterns.
Your view of the "best case XLS enhancement" (limit 100 words)
Detect at least trivial live-lock conditions and return errors if they are entered.
The text was updated successfully, but these errors were encountered: