This revision revisits the implementation of applyToOne and its handling
of recoverable errors as well as propagation of null handles.
The implementation is simplified to always require passing a vector<Operation*>
in which the results are returned, resulting in less template instantiation magic.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I think the entire null pointer mess should remain in the internal of applyToOne, i.e., if nulls are returned, just filter them out before calling results.set in the apply implementation by TransformEachTrait. The failure state is already propagated, so there is no reason to know about nulls above that. Furthermore, this will fail the moment two distinct results have nulls in them because it will create a conflict in the "payload op -> handle" mapping that expects only one handle per payload op and there will be multiple handles to null.
Even more, I don't think we want to expose the "null handle" idea to the op documentation. This is an implementation detail. It is also a handle pointing to some nulls and some ops, not a null handle AFAICS. We can instead explain the tri-state failure and describe the failure mode along the lines of "if the transformation fails to apply to a subset of payload IR ops associated with the operand handle, the resulting handles will be associated only with the payload IR operations produced by the successful applications; the overall result will be a silenceable failure that the containing operation may chose to silence or report".
mlir/include/mlir/Dialect/Transform/IR/TransformInterfaces.h | ||
---|---|---|
91 | Nit: I suppose we want to separate different messages by newlines or something. | |
135 | I'd rather consider a SmallVector<Diagnostic, 1> here with the convention that empty vector means no silenceable diagnostic. Currently, we can have an empty vector set, which is interpreted as silenceable diagnostic, but doesn't have any meaningful message. | |
599 | It is unclear what it should put in the vector in the normal case of success, and whether it can assume the vector to be empty or not. | |
600 | Nit: "this the" | |
602 | Which op? | |
610–613 | I'd mention that in the case of silenceable failure, the transformation will still be applied to the following target ops, but definite failures are propagated immediately. | |
757 | Micro-nit. | |
763–769 | Why changing the severity? Silenceable diagnostics from individual applications are likely errors, so this should be too. If the caller doesn't silence them, it will still be interpreted as failure. | |
824 | ||
837–840 | Because of the change above from "not success" to "is definite failure", this now looks incorrect in the following case. A transform op with legitimately zero results returns a silenceable failure and zero results. This will now turn that silenceable failure into a success. instead of collecting the failure message properly. | |
872 | Nit: this feels like a note that can be attached to the original message. |
mlir/include/mlir/Dialect/Transform/IR/TransformInterfaces.h | ||
---|---|---|
872 | I meant specifically the part that starts with a newline can be attached as a note to the error. This is how these things usually look: the error message, and the note "did you mean foo?" |
You seem have created separate review threads for the patches that were supposed to be addressing review in this one.
Fix test.
mlir/include/mlir/Dialect/Transform/IR/TransformInterfaces.h | ||
---|---|---|
872 | ah ok, thanks! |
Thanks!
mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgTransformOps.td | ||
---|---|---|
30 ↗ | (On Diff #442889) | s/vectorize/decompose |
mlir/include/mlir/Dialect/Transform/IR/TransformInterfaces.h | ||
764 | Nit: I'd drop the "null handle" part from here, the user doesn't necessarily know such details. | |
853–860 | Nit: would be nice to have a test. | |
mlir/test/Dialect/Transform/test-interpreter.mlir | ||
412–413 ↗ | (On Diff #442889) | Ultra-nit: missing whitespace |
Nit: I suppose we want to separate different messages by newlines or something.