Looking into this, it seems more difficult than initially thought to expose low-level operations to perform value replacement through the CAPI. We'd expect getUses to return OpOperands (by inheritance, IrOperand) which in turn is what we would call replace on.
Main pain points which i see here are:

1. OpOperand is heavily encapsulated to protect how and who can construct an operand. https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/IR/Value.h#L265
2. By the above, there's no immediate way that we can roundtrip the value through CAPI, which would require that an OpOperand can be constructed statically through an opaque pointer.

@rriddle do you have anything else you'd like too see done for the PR?

Address review comments.

reduce number of times each block is visited

address review comments

add missing early_inc_range and simplify tests

address review comments.

Rework the conversion pass into a transform utility. In doing so, also define a test pass for the filtered case. The transformation utility now takes a lambda to specify a value filter. The user-exposed pass convert-to-max-ssa no longer takes any arguments. For my own use-case, this is sufficient, since i'll be using the SSA maximization utility with a filtered type as a precondition for another conversion pass.

address review comments

update include

argument and control flow mappings should be stored for any value

missing }

incorrect namespace

In D108454#3009869, @mehdi_amini wrote:

I think you had tested this on an old revision but it failed CI at HEAD, can you rebase and fix the test before recommitting?

Address review comments

mising newline

I've added a rationale to the PR summary.

scf.execute_region ops are no longer necessary.

• Moved induction variable incrementation to start of while body
• updated tests

Fix clang-tidy nits

Remove redundant check lines

[MLIR][SCF] Use printOptionalArrowTypeList