Skip to content

[REFACTOR][IR] Migrate ObjectRef to not-null and use Optional #5318

@tqchen

Description

@tqchen

#5314 Introduced NotNull and optional support to the IR data structure.

We should start to track the migration of existing ObjectRef sub-classes to not-null by default to enhance the robustness throughout the codebase.

Update Guide

Right now the not-null ObjectRef is opt-in. That means by default an ObjectRef is nullable. We can gradually change the Ref types to not nullable, the steps are:

  • Change macro to TVM_DEFINE_NOTNULLABLE_OBJECT_REF_METHODS,
  • Remove the default constructor(if already defined) that corresponds to nullptr if there is a custom defined one.
    • Rationale: by removing the default constructor, it is unlikely to see an not-nullable ref to hold a nullptr, except for the case when it is moved(in which case we should not refer to then anyway)
    • If there is a method to construct an empty ObjectRef, we can use default constructor to do that(e.g. IRModule::Empty()->IRModule()).
  • Fix the compile error
    • For structs that takes the ref as a member, possibly due to unavailable default constructor, change to a new copy constructor
    • For cases that needs nullable version, use Optional

See example change for String https://github.com/apache/incubator-tvm/pull/5314/files#diff-6597547f217e514b638f9548fda1dbcaR528

So hopefully the upgrade will be smooth and incremental instead of a one-time big change. In the meanwhile, we do recommend to directly start using Optional<T> in cases where nullptr behavior is required.

Once we have migrated most of the Ref, we might decide to change the default behavior to opt-out. Which means, by default _type_is_nullable property for the ObjectRef is set to be true.

Engineering Implications and Example

Non-nullable refs does introduce a bit of engineering overhead. In particular, non-nullable refs may not have a default constructor(the default behavior of nullable refs defaults to nullptr) to let us enjoy more compile time checks. This means we need to introduce the member init constructor for each sub classes of ObjectNode to directly initialize them(to satisfy the invariance that these objects should be not null.

Say PrimExpr is notnullable.

class RangeNode : public Object {
 public:
   PrimExpr min;
   PrimExpr extent;
   // because min/extent does not have default constructor
   // we have to explicitly create such constructors
   RangeNode(PrimExpr min, PrimExpr extent)
     : min(min), extent(extent) {}
   // rest of the code
};

class Range : public ObjectRef {
 public:
   Range make_by_min_extent(PrimExpr min, PrimExpr extent) {
      // old-style no longer works, because there is no default constructor.
      // auto n = make_object<RangeNode>();
      //  n->min = std::move(min);
      //  n->extent = std::move(extent);
      // return Range(n);
      // Need to directly call the constructor of RangeNode to intialize the fields.
      return Range(make_object<RangeNode>(min, extent));
   }
};

Task Items

The refactor should starts with leaf nodes, while keeping most of the generic nodes(Expr, Stmt) still nullable first, so that we don't have to change the constructor all at once. Most of the tasks can be done in parallel, and only involves mechanical changes.

  • Array, Map, ADT -- might affect topi and need to move some of things to Items
    • NOTE: change to array will also affect the IR nodes that uses Array(e.g. CallNode), however, because Array has default constructor, it is fine to not change the IR nodes for now, although it will incurr additional cost(of constructing an Array then move another one by destroying the previous one).
  • IRModule
  • Pass/PassContext
  • Integer, Float, IntImm -- might affect topi
  • Leaf IR nodes of TIR nodes (e.g. AddNode, ForNode)
  • Leaf IR nodes of relay
  • Leaf nodes of type
  • BaseExpr, Type, TIR::Stmt (depends on previous leaf node tasks)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions