Add results to sv.ifdef

[prithayan]

This PR updates the sv.ifdef op to return results. We add a new op, sv.yield to return results from the sv.ifdef regions.
This enables us to use SSA values defined inside the sv.ifdef region, which is otherwise not possible. Since SSA values inside the sv.ifdef region, do not dominate any operations outside the region.
The motivation to add results to sv.ifdef is to support accessing Probes generated inside the sv.ifdef region.
In the FIRRTL dialect, it is possible to return probes defined in the sv.ifdef region as module output, but not in HW dialect. Consider this FIRRTL dialect example,

  firrtl.circuit "SimpleRefSend" {
    sv.macro.decl @LAYER_A
    firrtl.module @SimpleRefSend(in %clk: !firrtl.clock, out %probe_out: !firrtl.probe<uint<8>>) {
      sv.ifdef @LAYER_A {
        %w = firrtl.wire : !firrtl.uint<8>
        %0 = firrtl.ref.send %w : !firrtl.uint<8>
        firrtl.ref.define %probe_out, %0 : !firrtl.probe<uint<8>>
      }
    }
  }

We cannot lower this directly to the HW dialect, since the following is not a valid IR

  sv.macro.decl @LAYER_A
  hw.module @SimpleRefSend(in %clk : !seq.clock, out probe_out : !hw.probe<i8>) {
    %z_i8 = sv.constantZ : i8
    sv.ifdef @LAYER_A {
      %w = hw.wire %z_i8  : i8
      %1 = hw.probe.send %w : i8
    }
    hw.output %1 : !hw.probe<i8>
  }

But we can generate the following valid IR using the proposed sv.yield

  sv.macro.decl @LAYER_A
  hw.module @SimpleRefSend(in %clk : !seq.clock, out probe_out : !hw.probe<i8>) {
    %z_i8 = sv.constantZ : i8
    %probe = sv.ifdef @LAYER_A -> !hw.probe<i8> {
      %w = hw.wire %z_i8  : i8
      %1 = hw.probe.send %w : i8
       sv.yield %1 : !hw.probe<i8>
    }
    hw.output %probe : !hw.probe<i8>
  }

The if then and else regions can have independent results from each region. The results from both the regions are concatenated.

    // Returns 2 results: i32 from then, i64 from else
    %0:2 = sv.ifdef @MACRO -> i32, i64 {
      %then_val = ...
      sv.yield %then_val : i32
    } else {
      %else_val = ...
      sv.yield %else_val : i64
    }

In this implementation, there is no legal lowering of this in ExportVerilog and it is assumed that some earlier pass should lower them appropriately.
For the probes use case, a (proposed) HW::LowerXMR pass will generate hierarchical reference to the corresponding targets and remove any results from the sv.ifdef.
Any verilog lowering for this is not supported, since it can result in (illegal) dead code.

Why the result concatenation, instead of constraining the then and else region to return same result types ?

Since, sv.ifdef is not a normal SSA conditional; it models a Verilog preprocessor conditional. The then/else regions are independently-formed textual regions, and Verilog does not require the declarations or values in one branch to correspond to those in the other. Because of that, forcing both branches to have the same result types would add a constraint that does not exist in the source semantics. Concatenating the yielded values preserves the natural independence of the two regions: values from the then region stay distinct from values from the else region, instead of being forced into an artificial pairwise merge.
It is the responsibility of the circt pass generating this sv.ifdef with results to ensure the legality of the IR. For example the result from the then region can only be used when the corresponding condition is true.

[circt-bot]

Results of circt-tests run for dd5f7ab compared to results for d8bbbc6: no change to test results.

[uenoku]

I know the context internally but could you mention why the standard lowering (sv.wire + sv.assign) doesn't work?

The if then and else regions can have independent results from each region. The results from both the regions are concatenated.

I think this representation is very non-standard. Can we make sv.ifdef branches have same result types, and return poison from an illegal branch for probe use case?

HW::LowerXMR pass will generate hierarchical reference to the corresponding targets and remove any results from the sv.ifdef.

So it means we cannot legalize ifdef with results in a normal SV pipeline (basically non-Chisel flow)? I understand LowerXMR requires very specific shape of verilog. However in that case I wonder if it's less invasive to introduce a new operation instead of creating a non-emittable sv.ifdef variant.