[RFC] Modify IfOp in Loop dialect to yield values

[bondhugula]

@schweitz

@schweitz

Yes, return is overloaded. (And the distinction between return and loop.return isn’t all that.) But returning a value seems a bit more natural than yielding a value to me. Yield suggests some sort of coroutine arrangement where the value may be picked up by another thread or something. In lieu of a perfect name here, I was going for something less likely to mislead.

The value is not returned in this case, though. If I saw a return , I would expect that the value is returned by the loop.for . I would for sure be confused at which value that would be but it would be my first assumption.

+1. Although per the region’s semantics, irrespective of which terminator you use, the value is always returned out of the region and to the parent op to handle, readability-wise, it might be confusing to use ‘return’ in cases where the returned value(s) don’t bind 1:1 with the parent op’s result values. For loop.for, such a binding only happens for the last iteration; hence, I think it’s more readable to use something other than std.return or for that matter something other than loop.return. However, in cases, where the returned value binds 1:1 with the result value whenever something is returned (like in std.func, std.execute_region, affine.graybox, all other declarative function like ops that exist in MLIR, even loop.if), using return is both readable and obviously semantics-wise valid. Allowing reuse of std.return in cases like these is the motivation behind untying std.return from FuncOp (https://reviews.llvm.org/D71961 ), but this has been pending for over a month now! Its immediate use case is execute_region / inlined_call.