Add separate, explicit read_request() and read_response() methods to …

Add decomposition for Eq and Ne operations.

This change extends the DecomposeDataflowPass to handle equality (Eq) and inequality (Ne) operations on composite types (arrays or tuples). When encountering an Eq or Ne on non-scalar operands, the pass decomposes the operation into element-wise comparisons. For Eq, the results of the element-wise comparisons are combined with an And. For Ne, the results are combined with an Or.

PiperOrigin-RevId: 904156592

Add IR conversion logic for simple impl-style procs that do not spawn…

Enable the use of ProcDef-based ProcIds.

Since we are only going to use use ProcDefs with proc-scoped channels, we don't need the stack part of ProcId (PSC never populates it as originally intended anyway).

PiperOrigin-RevId: 902904668

Refactor: Use NodeNameFormat and NodeNameConcat for node naming in pa…

Drop XLS_FRIEND_TEST in favor of public FRIEND_TEST.

PiperOrigin-RevId: 900347783

Add parsing support for spawns of impl-style procs.

Spawns of legacy procs will continue to look like:
```spawn Foo(config_args);```

Spawns of impl-style procs will look like an invocation of a trait-derived function:
```foo_instance.spawn();``` or ```Foo::new(args).spawn()``` or similar. This will become a regular Invocation node and not a Spawn node. We will not need Spawn nodes anymore once we get rid of the legacy syntax.

To make this work, this change makes "spawn" not a keyword anymore.

PiperOrigin-RevId: 899782677

Automated Code Change

PiperOrigin-RevId: 899390394

Integrate LLVM at llvm/llvm-project@815edc3ff646

Updates LLVM usage to match
[815edc3ff646](https://github.com/llvm/llvm-project/commit/815edc3ff646)

PiperOrigin-RevId: 897843053

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