Lunderberg commented on code in PR #16827:
URL: https://github.com/apache/tvm/pull/16827#discussion_r1547859309
##########
src/relax/op/op_common.h:
##########
@@ -239,52 +239,91 @@ InferLayoutOutput InferLayoutUnaryEwise(const Call& call,
const Map<String, Array<String>>&
desired_layouts,
const VarLayoutMap& var_layout_map);
+/*!
+ * \brief Get the element dtype from StructInfo
+ *
+ * \param sinfo The StructInfo to expect
+ * \return The inferred element dtype.
+ * \throw Throw exception if the StructInfo doesn't have an element type.
+ */
+inline DataType GetElementDType(const StructInfo& sinfo) {
+ if (const auto* prim = sinfo.as<PrimStructInfoNode>()) {
+ return prim->dtype;
+ } else if (const auto* tensor = sinfo.as<TensorStructInfoNode>()) {
+ return tensor->dtype;
+ } else if (sinfo.as<ObjectStructInfoNode>()) {
+ return DataType::Void();
Review Comment:
Yeah, I went back and forth on it. There isn't currently a standard for
whether `FInferStructInfo` should raise an error when the arguments are
provably invalid, or if it should raise an error when the arguments are not
provably valid. On the one hand, `StructInfoLCA` returns `ObjectStructInfo` as
the common base class of `TensorStructInfo` and `PrimStructInfo`, so an
`ObjectStructInfo` could contain a valid instance of either. On the other
hand, the current struct inference requires that the input be validated as
`TensorStructInfo`.
Overall, I'm not sure which is the better behavior. For now, I'm updating
this PR to explicitly require either `TensorStructInfo` or `PrimStructInfo`,
and to raise an exception for `ObjectStructInfo`, since allowing
`ObjectStructInfo` would be an independent change.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
