Releases: google/xls
Releases · google/xls
v0.0.0-9840-gd53059466
Automated Code Change PiperOrigin-RevId: 899390394
v0.0.0-9830-g5389a52b3
Integrate LLVM at llvm/llvm-project@815edc3ff646 Updates LLVM usage to match [815edc3ff646](https://github.com/llvm/llvm-project/commit/815edc3ff646) PiperOrigin-RevId: 897843053
v0.0.0-9821-gbac56261d
Fix for redundant break statements in nested scopes.
Generated by Gemini. Its explanation:
✦ The PipelinedLoopOuterExit test case fails when the break on line 10929 of the test file is present because of a bug in xls/contrib/xlscc/translator.cc where
relative_break_condition was being overwritten by subsequent break statements instead of being accumulated.
Root Cause Analysis
In translator.cc, within the GenerateIR_Stmt function, the handling for clang::BreakStmt and clang::ContinueStmt used simple assignment (=) for relative_break_condition and
relative_continue_condition.
1 // Original buggy code in translator.cc
2 context().relative_break_condition = context().relative_condition_bval(loc);
When a loop body contains multiple break statements, such as:
1 if (x > 10) {
2 if (x == 55) {
3 exit_function = true;
4 break; // Break 1
5 }
6 break; // Break 2
7 }
The translator processes both break statements. When x == 55, Break 1 correctly sets the relative_break_condition. However, the translator continues to process Break 2. Although Break 2 is
logically unreachable in C++ when Break 1 is taken, the translator still evaluates it with its current relative_condition. Because Break 1 calls and_condition(0) to make the rest of the
block a no-op, the relative_condition for Break 2 becomes 0. The assignment relative_break_condition = 0 then overwrites the valid break condition from Break 1, causing the generated IR to
lose the signal to exit the loop.
Fix
The fix involves using or_condition_util to OR the new break/continue condition with any existing ones, ensuring that all possible exit paths are preserved.
1 // Fixed code in translator.cc
2 context().or_condition_util(context().relative_condition_bval(loc),
3 context().relative_break_condition, loc);
This ensures that if any break in the current context is triggered, the relative_break_condition remains true. I have applied this fix to both BreakStmt (for both for and switch bodies)
and ContinueStmt in translator.cc.
PiperOrigin-RevId: 897394101
v0.0.0-9811-g80aabc16e
`ComputeMutualExclusionAnalysis`' criteria for including nodes should…
v0.0.0-9805-g801871b93
Fix bug where PSC IR conversion drops trait-derived functions too eag…
v0.0.0-9799-g05e11874e
Ensure source-location info is tracked for proc state-reads We would simply drop this information and not record it. With the separate state_read operation tracking and parsing this information is automatic so there is no need to do that anymore. PiperOrigin-RevId: 895512634
v0.0.0-9792-g96de24122
Move pprof dep to MODULE.bazel instead of loading it from WORKSPACE. PiperOrigin-RevId: 894762182
v0.0.0-9791-g1736de8c4
Migrate to Bazel proto_library rules from protobuf dep. Resolves deprecation warning for py_proto_library. The rules_python version was removed and just redirects to the protobuf version since rules_python 1.2.0. See https://github.com/bazel-contrib/rules_python/blob/900d55725f3573b29b93212d19eb7f31e13c4546/python/proto.bzl#L18-L21. cc_proto_library was added to protobuf in 29.0 (and removed as a built-in in Bazel 8). See https://protobuf.dev/news/v29/#bazel-and-proto-rules. PiperOrigin-RevId: 894343559
v0.0.0-9775-gc898c3189
Integrate LLVM at llvm/llvm-project@7ccd92e5e6e5 Updates LLVM usage to match [7ccd92e5e6e5](https://github.com/llvm/llvm-project/commit/7ccd92e5e6e5) PiperOrigin-RevId: 893768833
v0.0.0-9766-gb386ad425
[opt] Use ReachableFrom rather than TransitiveClosure This change introduces the ReachableFrom functions, which compute the set of nodes reachable from a given set of starting nodes in a directed graph. We support both adjacency lists & dense graphs represented using InlineBitmaps. The register cleanup pass and proc state optimization pass are updated to use these new functions, replacing manual worklist implementations or less efficient transitive closure computations (O(N^3) vs. O(N+E)). PiperOrigin-RevId: 893187430