Users can be OpOperands or Value::BlockArguments

[rikhuijzer]

Given some op result like %0 in, for example,

%0 = arith.constant 1 : i32
%1 = arith.constant 2 : i32
%2 = arith.addi %0, %1 : i32

it is clear that the user is arith.addi where the usage is via the OpOperand %0.

However, it is also possible to have the following usage:

%c1_i32 = arith.constant 1 : i32
%1 = cf.br ^bb3(%c1_i32 : i32)

Now the usage is via a Value::BlockArgument.

This is a problem for the users function since there is no supertype for these types.

[rikhuijzer]

The solution is probably to parse %c1_i32 : i32 to an operand of type OpResult in

%1 = cf.br ^bb3(%c1_i32 : i32)

This way, all the normal logic still works.

As far as I can see, this shouldn't give problems with more complex branching like cf.cond_br. For example, this case doesn't pass an argument in the cf.cond_br:

func.func @main() -> i32 {
  %0 = arith.constant 0 : i1
  %3 = arith.constant 3 : i32
  %1 = scf.if %0 -> (i32) {
    scf.yield %3 : i32
  } else {
    %4 = arith.constant 4 : i32
    scf.yield %4 : i32
  }
  return %1 : i32
}

mlir-opt --convert-scf-to-cf tmp.mlir:

module {
  func.func @main() -> i32 {
    %false = arith.constant false
    %c3_i32 = arith.constant 3 : i32
    cf.cond_br %false, ^bb1, ^bb2
  ^bb1:  // pred: ^bb0
    cf.br ^bb3(%c3_i32 : i32)
  ^bb2:  // pred: ^bb0
    %c4_i32 = arith.constant 4 : i32
    cf.br ^bb3(%c4_i32 : i32)
  ^bb3(%0: i32):  // 2 preds: ^bb1, ^bb2
    cf.br ^bb4
  ^bb4:  // pred: ^bb3
    return %0 : i32
  }
}