[Mlir-commits] [mlir] [mlir] NFC: Clarify documentation on InferShapedTypeOpInterface::inferReturnTypeComponents (PR #70350)

Felix Schneider llvmlistbot at llvm.org
Fri Oct 27 01:20:01 PDT 2023


================
@@ -142,6 +142,9 @@ def InferShapedTypeOpInterface : OpInterface<"InferShapedTypeOpInterface"> {
       Unknown (e.g., unranked) shape and nullptrs for element type and attribute
       may be returned by this function while returning success. E.g., partial
       population of components is not error condition.
+
+      Be aware that this method is supposed to be called with valid arguments,
+      e.g., operands are verified, or it may result in an undefined behavior.
----------------
ubfx wrote:

The reason I originally suggested on discord to copy this sentence over is that both `InferTypeOpInterface` and `InferShapedTypeOpInterface` have the same phrase in the `description`, saying: "[...] could be used during op construction, verification or type inference", but only one (`inferTypeOpInterface`) has the phrase saying "the operands need to be verified". I understood @jpienaar's explanation as meaning that since both methods could be used under the same circumstances (i.e. potentially verifier), it would be consistent for them to have the same requirements about operands. Did I misunderstand this?

I was trying to get a better understanding of how these methods are used but couldn't find anything in tree, could you point me to an example? I guess I don't understand why the possibility of using the methods in the verifier means that they cannot assume the operands are valid? The verifier could check the operands and attributes, and if it hasn't errored out by then, it could call `inferReturnType/Components`.

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


More information about the Mlir-commits mailing list