[Mlir-commits] [mlir] [MLIR][SCF] Add dedicated Python bindings for ForallOp (PR #149416)

Colin De Vlieghere llvmlistbot at llvm.org
Fri Jul 18 14:18:43 PDT 2025


Cubevoid wrote:

> > For example the existing for_ helper with the argument yielding lives alongside the ForOp class which has more properties you can access.
> 
> Yes of course having what you've contributed here is good as far as providing access to attributes and etc but what I'm saying is if you provide the `scf.ForAllOp.terminator` API then if/when I/we/you introduce the `for x in scf.forall` pattern and people try to emit a terminator in the body using the `.terminator()` method it'll be incompatible with the generator.
> 
> Ok having said that I think I'm being unnecessarily cautious because in that pattern there's actually not even a way to access the class instance itself. So nevermind my that complaint - your version is good to land 😄 .
> 
> The only thing I'll say is that you haven't handled `shared_outs` which I handled in my version:
> 
> ```python
> class ForallOp(ForallOp):
>     def __init__(
>         ...
>         shared_outs: Optional[Union[Operation, OpView, Sequence[Value]]] = None,
>         ...
>     ):
>         ...
>         if shared_outs is not None:
>             results = [o.type for o in shared_outs]
>         else:
>             results = shared_outs = []
>         ...
> 
>         super().__init__(
>             ...
>             outputs=shared_outs,
>             ...
>         )
> ```
> 
> Can you add that?

Oh yeah I named it `iter_args` in this PR, but I can rename it to `shared_outs` since that is more appropriate for this op.

https://github.com/llvm/llvm-project/pull/149416


More information about the Mlir-commits mailing list