[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