Skip to content

Releases: google/xls

v0.0.0-9840-gd53059466

14 Apr 08:21

Choose a tag to compare

Automated Code Change

PiperOrigin-RevId: 899390394

v0.0.0-9830-g5389a52b3

11 Apr 08:10

Choose a tag to compare

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

10 Apr 08:19

Choose a tag to compare

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

09 Apr 08:20

Choose a tag to compare

`ComputeMutualExclusionAnalysis`' criteria for including nodes should…

v0.0.0-9805-g801871b93

08 Apr 08:21

Choose a tag to compare

Fix bug where PSC IR conversion drops trait-derived functions too eag…

v0.0.0-9799-g05e11874e

07 Apr 08:18

Choose a tag to compare

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

05 Apr 08:12

Choose a tag to compare

Move pprof dep to MODULE.bazel instead of loading it from WORKSPACE.

PiperOrigin-RevId: 894762182

v0.0.0-9791-g1736de8c4

04 Apr 08:10

Choose a tag to compare

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

03 Apr 08:15

Choose a tag to compare

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

02 Apr 08:18

Choose a tag to compare

[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