Report an error when trying to bufferize an op that contains unstructured control flow but for ops for which the bufferization implementation does not support unstructured control flow. At the moment, there are no ops for which unstructured control flow is supported.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I have a few questions regarding the motivation of this change:
Is this intended to be a temporal solution to slowly add support for unstructured control-flow one op after another?
Shouldn't the goal be that every op that implements the bufferization interface and may have multiple blocks in a region (unstructured control-flow) should implement the interface in a way that the region can be properly bufferized?
Are there fundamental limitations to when unstructured contol flow can be bufferized? If so, is it fine-grained enough to check for multiple blocks in a region or should there be some method like isBufferizable such that ops can check whether they are bufferizable more dynamically and provide an adequate error message if not?
Kind of. The blocks of a region are bufferized together with the owner of that region. E.g., the BufferizableOpInterface implementation of func.func is responsible for bufferizing all block signatures directly nested under that op. We do not support unstructured control flow yet, so no implementations actually support that at the moment. I added a new interface method so that interface implementations that support unstructured control flow can override that function with true. This gives us proper error messages instead of failed assertions in case it is not supported.
I expect this new interface method to stay indefinitely to give proper error messages for downstream ops that may support unstructured control flow and where the implementer of the BufferizableOpInterface did not account for that.
Shouldn't the goal be that every op that implements the bufferization interface and may have multiple blocks in a region (unstructured control-flow) should implement the interface in a way that the region can be properly bufferized?
Yes. In practice we will not have many ops. func.func and scf.execute_region should be the only ops in MLIR for now.
Are there fundamental limitations to when unstructured contol flow can be bufferized?
No, a simple bufferization strategy that always works is "make a copy of the buffer and pass that one to the cf.br."
Thanks for providing more info! In that case it's not necessary to allow more fine-grained decisions.
I guess that, given all terminators in the region implement the BranchOpInterface, it is possible to provide the bufferization logic for unstructured control flow as a library function that the downstream users could just call and thus make it very easy to add support for them?
Nonetheless, I think it's better to present some nice error message if support was not added rather than throwing an assertion (even though you could argue that an assertion is good enough when an interface is implemented incorrectly).
mlir/include/mlir/Dialect/Bufferization/IR/BufferizableOpInterface.td | ||
---|---|---|
535 | Would it make sense to make this a static method since it probably does not need to access fields of the op, but only informs the user of the interface (i.e., one-shot bufferization) about a property of the interface implementation? |
Would it make sense to make this a static method since it probably does not need to access fields of the op, but only informs the user of the interface (i.e., one-shot bufferization) about a property of the interface implementation?