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

Felix Schneider llvmlistbot at llvm.org
Mon Oct 30 04:27:38 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:

> or we should treat the input as "unsafe" (which is the case here)

Makes sense. I understand now why we potentially have to tolerate unverified operands here, but I still don't fully understand the difference between `inferReturnTypes` and `inferReturnTypeComponents` regarding this.

> It's an ordering question: the verifier one can set different orderings, and AFAIK verification of number of operands etc occur before trait verification (but please check me on this) so that it does handle many cases in the verifier.

Would it make sense to point out in the documentation for both methods, that they need to be able to tolerate "unsafe" (i.e. not fully verified) inputs, although the "degree of unsafeness" might vary depending at which stage of the verifier they are called?


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


More information about the Mlir-commits mailing list