[Refactor] Clean up Relay references in the codebase (#17733)

Removing relay references and statements in the codebase.

Author: Hzfengsy

cmake/config.cmake

@@ -248,12 +248,12 @@ set(USE_SORT ON)
 
 # Whether to use Arm Compute Library (ACL) codegen
 # We provide 2 separate flags since we cannot build the ACL runtime on x86.
-# This is useful for cases where you want to cross-compile a relay graph
+# This is useful for cases where you want to cross-compile a graph
 # on x86 then run on AArch.
 #
 # An example of how to use this can be found here: docs/deploy/arm_compute_lib.rst.
 #
-# USE_ARM_COMPUTE_LIB - Support for compiling a relay graph offloading supported
+# USE_ARM_COMPUTE_LIB - Support for compiling a graph offloading supported
 #                       operators to Arm Compute Library. OFF/ON
 # USE_ARM_COMPUTE_LIB_GRAPH_EXECUTOR - Run Arm Compute Library annotated functions via the ACL
 #                                     runtime. OFF/ON/"path/to/ACL"
@@ -263,7 +263,7 @@ set(USE_ARM_COMPUTE_LIB_GRAPH_EXECUTOR OFF)
 # Whether to build with TensorRT codegen or runtime
 # Examples are available here: docs/deploy/tensorrt.rst.
 #
-# USE_TENSORRT_CODEGEN - Support for compiling a relay graph where supported operators are
+# USE_TENSORRT_CODEGEN - Support for compiling a graph where supported operators are
 #                        offloaded to TensorRT. OFF/ON
 # USE_TENSORRT_RUNTIME - Support for running TensorRT compiled modules, requires presence of
 #                        TensorRT library. OFF/ON/"path/to/TensorRT"

cmake/modules/CUDA.cmake

@@ -70,8 +70,8 @@ if(USE_CUDA)
   if(USE_CUDNN)
     message(STATUS "Build with cuDNN support")
     include_directories(SYSTEM ${CUDA_CUDNN_INCLUDE_DIRS})
-    tvm_file_glob(GLOB CUDNN_RELAY_CONTRIB_SRC src/relay/backend/contrib/cudnn/*.cc src/relax/backend/contrib/cudnn/*.cc)
-    list(APPEND COMPILER_SRCS ${CUDNN_RELAY_CONTRIB_SRC})
+    tvm_file_glob(GLOB CUDNN_RELAX_CONTRIB_SRC src/relax/backend/contrib/cudnn/*.cc)
+    list(APPEND COMPILER_SRCS ${CUDNN_RELAX_CONTRIB_SRC})
     tvm_file_glob(GLOB CONTRIB_CUDNN_SRCS src/runtime/contrib/cudnn/*.cc)
     list(APPEND RUNTIME_SRCS ${CONTRIB_CUDNN_SRCS})
     list(APPEND TVM_RUNTIME_LINKER_LIBS ${CUDA_CUDNN_LIBRARY})
@@ -95,7 +95,7 @@ if(USE_CUDA)
 
   if(USE_CUBLAS)
     message(STATUS "Build with cuBLAS support")
-    tvm_file_glob(GLOB CUBLAS_CONTRIB_SRC src/relay/backend/contrib/cublas/*.cc src/relax/backend/contrib/cublas/*.cc)
+    tvm_file_glob(GLOB CUBLAS_CONTRIB_SRC src/relax/backend/contrib/cublas/*.cc)
     list(APPEND COMPILER_SRCS ${CUBLAS_CONTRIB_SRC})
     tvm_file_glob(GLOB CONTRIB_CUBLAS_SRCS src/runtime/contrib/cublas/*.cc)
     list(APPEND RUNTIME_SRCS ${CONTRIB_CUBLAS_SRCS})

cmake/modules/contrib/ArmComputeLib.cmake

@@ -18,7 +18,7 @@
 # We separate the codegen and runtime build since ACL can only be built
 # for AArch. In the world where we take the cross compilation approach,
 # which is common with arm devices, we need to be able to cross-compile
-# a relay graph on x86 for AArch and then run the graph on AArch.
+# a graph on x86 for AArch and then run the graph on AArch.
 if(USE_ARM_COMPUTE_LIB)
     tvm_file_glob(GLOB ACL_RUNTIME_MODULE src/runtime/contrib/arm_compute_lib/acl_runtime.cc)
 

cmake/modules/contrib/BNNS.cmake

@@ -17,9 +17,8 @@
 
 if(USE_BNNS STREQUAL "ON")
   add_definitions(-DUSE_JSON_RUNTIME=1)
-  tvm_file_glob(GLOB BNNS_RELAY_CONTRIB_SRC src/relay/backend/contrib/bnns/*.cc)
+  tvm_file_glob(GLOB BNNS_RELAY_CONTRIB_SRC "")
   list(APPEND COMPILER_SRCS ${BNNS_RELAY_CONTRIB_SRC})
-  list(APPEND COMPILER_SRCS ${JSON_RELAY_CONTRIB_SRC})
 
   list(APPEND TVM_RUNTIME_LINKER_LIBS "-framework Accelerate")
 

cmake/modules/contrib/DNNL.cmake

@@ -21,7 +21,7 @@ if(IS_DIRECTORY ${USE_DNNL})
     message(WARNING "Cannot find DNNL library at ${USE_DNNL}.")
   else()
     add_definitions(-DUSE_JSON_RUNTIME=1)
-    tvm_file_glob(GLOB DNNL_CONTRIB_SRC src/relay/backend/contrib/dnnl/*.cc src/relax/backend/contrib/dnnl/*.cc)
+    tvm_file_glob(GLOB DNNL_CONTRIB_SRC src/relax/backend/contrib/dnnl/*.cc)
     list(APPEND COMPILER_SRCS ${DNNL_CONTRIB_SRC})
 
     list(APPEND TVM_RUNTIME_LINKER_LIBS ${EXTERN_LIBRARY_DNNL})
@@ -34,7 +34,7 @@ if(IS_DIRECTORY ${USE_DNNL})
   endif()
 elseif((USE_DNNL STREQUAL "ON") OR (USE_DNNL STREQUAL "JSON"))
   add_definitions(-DUSE_JSON_RUNTIME=1)
-  tvm_file_glob(GLOB DNNL_CONTRIB_SRC src/relay/backend/contrib/dnnl/*.cc src/relax/backend/contrib/dnnl/*.cc)
+  tvm_file_glob(GLOB DNNL_CONTRIB_SRC  src/relax/backend/contrib/dnnl/*.cc)
   list(APPEND COMPILER_SRCS ${DNNL_CONTRIB_SRC})
 
   find_library(EXTERN_LIBRARY_DNNL dnnl)
@@ -46,9 +46,6 @@ elseif((USE_DNNL STREQUAL "ON") OR (USE_DNNL STREQUAL "JSON"))
   list(APPEND RUNTIME_SRCS ${DNNL_CONTRIB_SRC})
   message(STATUS "Build with DNNL JSON runtime: " ${EXTERN_LIBRARY_DNNL})
 elseif(USE_DNNL STREQUAL "C_SRC")
-  tvm_file_glob(GLOB DNNL_RELAY_CONTRIB_SRC src/relay/backend/contrib/dnnl/*.cc)
-  list(APPEND COMPILER_SRCS ${DNNL_RELAY_CONTRIB_SRC})
-
   find_library(EXTERN_LIBRARY_DNNL dnnl)
   list(APPEND TVM_RUNTIME_LINKER_LIBS ${EXTERN_LIBRARY_DNNL})
   tvm_file_glob(GLOB DNNL_CONTRIB_SRC src/runtime/contrib/dnnl/dnnl.cc

cmake/modules/contrib/Mrvl.cmake

@@ -24,9 +24,4 @@ if(USE_MRVL)
     src/runtime/contrib/mrvl/mrvl_sw_runtime_lib.cc
   )
   list(APPEND RUNTIME_SRCS ${RUNTIME_MRVL_SRCS})
-  file(GLOB COMPILER_MRVL_SRCS
-    src/relay/backend/contrib/mrvl/codegen.cc
-    src/relay/backend/contrib/mrvl/compiler_attr.cc
-  )
-  list(APPEND COMPILER_SRCS ${COMPILER_MRVL_SRCS})
 endif(USE_MRVL)

cmake/modules/contrib/TensorRT.cmake

@@ -23,7 +23,7 @@ include (FindPackageHandleStandardArgs)
 
 if(USE_TENSORRT_CODEGEN)
     message(STATUS "Build with TensorRT codegen")
-    tvm_file_glob(GLOB COMPILER_TENSORRT_SRCS src/relay/backend/contrib/tensorrt/*.cc src/relax/backend/contrib/tensorrt/*.cc)
+    tvm_file_glob(GLOB COMPILER_TENSORRT_SRCS src/relax/backend/contrib/tensorrt/*.cc)
     set_source_files_properties(${COMPILER_TENSORRT_SRCS} PROPERTIES COMPILE_FLAGS "-Wno-deprecated-declarations")
     tvm_file_glob(GLOB RUNTIME_TENSORRT_SRCS src/runtime/contrib/tensorrt/tensorrt_runtime.cc)
     set_source_files_properties(${RUNTIME_TENSORRT_SRCS} PROPERTIES COMPILE_FLAGS "-Wno-deprecated-declarations")

docs/arch/index.rst

@@ -114,7 +114,7 @@ Target Translation
 The target translation phase transforms an IRModule to the corresponding target executable format.
 For backends such as x86 and ARM, we use the LLVM IRBuilder to build in-memory LLVM IR.
 We can also generate source-level languages such as CUDA C and OpenCL.
-Finally, we support direct translations of a Relay function (sub-graph) to specific targets via external code generators.
+Finally, we support direct translations of a Relax function (sub-graph) to specific targets via external code generators.
 It is important that the final code generation phase is as lightweight as possible. Vast majority of transformations
 and lowering should be performed before the target translation phase.
 
@@ -175,8 +175,8 @@ In summary, the key data structures in the compilation flows are:
 
 Most parts of the compilation are transformations among the key data structures.
 
-- relay/transform and tir/transform are determinstic rule-based transformations
-- auto_scheduler and autotvm contains the search-based transformations
+- relax/transform and tir/transform are determinstic rule-based transformations
+- meta-schedule contains the search-based transformations
 
 Finally, the compilation flow example is only a typical use-case of the TVM stack.
 We expose these key data structures and transformations to python and C++ APIs. As a result, you can use TVM just like the way you use numpy,
@@ -247,7 +247,7 @@ The ability to save/store, and inspect an IR node provides a foundation for maki
 tvm/ir
 ------
 The `tvm/ir` folder contains the unified data structure and interfaces across for all IR function variants.
-The components in `tvm/ir` are shared by `tvm/relay` and `tvm/tir`, notable ones include
+The components in `tvm/ir` are shared by `tvm/relax` and `tvm/tir`, notable ones include
 
 - IRModule
 - Type

docs/arch/pass_infra.rst

@@ -20,7 +20,7 @@
 Pass Infrastructure
 ===================
 
-Both Relay and TVM IR contain a series of optimization passes which improve performance metrics
+Both Relax and TVM IR contain a series of optimization passes which improve performance metrics
 of models such as mean inference, memory footprint, or power consumption for
 specific devices. There is a suite of standard optimizations as well as machine
 learning-specific optimizations including constant folding, dead code
@@ -31,7 +31,7 @@ transformation using the analysis result collected during and/or before traversa
 However, as TVM evolves quickly, the need for a more systematic and efficient
 way to manage these passes is becoming apparent. In addition, a generic
 framework that manages the passes across different layers of the TVM stack (e.g.
-Relay and tir) paves the way for developers to quickly prototype and plug the
+Relax and tir) paves the way for developers to quickly prototype and plug the
 implemented passes into the system.
 
 This doc describes the design of such an infra that takes the advantage of the
@@ -51,7 +51,7 @@ scheme through `Sequential`_ and `Block`_, respectively. With such constructs,
 these modern frameworks are able to conveniently add modules/layers to their
 containers and build up neural networks easily.
 
-The design of the Relay pass infra is largely inspired by the hierarchical
+The design of the TVM pass infra is largely inspired by the hierarchical
 pass manager used in LLVM and the block-style containers used in the popular
 deep learning frameworks. The major goals of the pass infra include:
 
@@ -170,7 +170,7 @@ Pass Constructs
 ^^^^^^^^^^^^^^^
 
 The pass infra is designed in a hierarchical manner, and it could work at
-different granularities of Relay/tir programs. A pure virtual class ``PassNode`` is
+different granularities of Relax/tir programs. A pure virtual class ``PassNode`` is
 introduced to serve as the base of the different optimization passes. This class
 contains several virtual methods that must be implemented by the
 subclasses at the level of modules, functions, or sequences of passes.
@@ -200,7 +200,7 @@ Module-Level Passes
 
 Module level passes are geared mainly for global and inter-procedural
 optimizations (IPO), which are similar to the module pass used in LLVM. Some
-typical passes in Relay that need the global picture of a module, such as
+typical passes in Relax that need the global picture of a module, such as
 A-normal form conversion and lambda lifting, etc., fall into this set. At this
 level, users can even add and/or delete functions in a module. Note that all
 passes
@@ -226,13 +226,13 @@ Function-Level Passes
 ^^^^^^^^^^^^^^^^^^^^^
 
 Function-level passes are used to implement various intra-function level
-optimizations for a given Relay/tir module. It fetches one function at a time from
-the function list of a module for optimization and yields a rewritten Relay
+optimizations for a given Relax/tir module. It fetches one function at a time from
+the function list of a module for optimization and yields a rewritten Relax
 ``Function`` or tir ``PrimFunc``. Most of passes can be classified into this category, such as
-common subexpression elimination and inference simplification in Relay as well as vectorization
+common subexpression elimination and inference simplification in Relax as well as vectorization
 and flattening storage in tir, etc.
 
-Note that the scope of passes at this level is either a Relay function or a tir primitive function.
+Note that the scope of passes at this level is either a Relax function or a tir primitive function.
 Therefore, we cannot add or delete a function through these passes as they are not aware of
 the global information.
 

include/tvm/ir/transform.h

@@ -32,18 +32,18 @@
  *  - Reducing the effort required to implement new passes for compiler
  * developers, etc.
  *
- * Similar to LLVM's pass manager, we designed the Relay/Relax pass manager to work
+ * Similar to LLVM's pass manager, we designed the Relax pass manager to work
  * different granularity, i.e. module level, function level, and even sequential
  * passe that contains a host of passes.
  *
  * However, we also extend the functionality of the traditional pass manager
  * with the consideration of requirements/convention from deep learning
- * frameworks, such as Pytorch and Gluon, etc. Each pass in the Relay/Relax pass
+ * frameworks, such as Pytorch and Gluon, etc. Each pass in the Relax pass
  * manager performs the IRModule -> IRModule transformation. All
  * different types of passes, including the sequential-level pass object, are
  * essentially pass objects. This design, therefore, effectively provides users
  * a consistent and convenient interface, i.e. Pass, to play with. It offers a
- * means to ease the development and testing of Relay/Relax passes. For example, with
+ * means to ease the development and testing of Relax passes. For example, with
  * the pass manager, external users will be able to have custom passes correctly
  * scheduled without having to modify a single handcrafted pass order.
  *
@@ -387,7 +387,7 @@ class PassInfo : public ObjectRef {
 /*!
  * \brief PassNode is the base type of differnt types of optimization passes.
  * It is designed as a pure class and implemented by different pass subclasses
- * at different granularity of Relay/Relax nodes.
+ * at different granularity of Relax nodes.
  */
 class PassNode : public Object {
  public:
@@ -460,7 +460,7 @@ class Pass : public ObjectRef {
 };
 
 /*!
- * \brief The SequentialNode contains a set of passes that transform Relay/Relax
+ * \brief The SequentialNode contains a set of passes that transform Relax
  * programs from one AST to another semantically equivalent one.
  *
  * One example of this level of pass is that the pass manager needs to correctly

include/tvm/ir/type.h

@@ -21,7 +21,7 @@
  * \file tvm/ir/type.h
  * \brief IR/AST nodes for the unified type system in TVM.
  *
- * We use Relay's type system as the unified type system
+ * We use TVM's type system as the unified type system
  * throughout the stack.
  *
  * This file contains types that are common across IR variants.
@@ -62,7 +62,7 @@ namespace tvm {
 /*!
  * \brief Type is the base type of all types.
  *
- * Relay's type system contains following subclasses:
+ * TVM's type system contains following subclasses:
  *
  * - PrimType: type of primitive type values used in the low-level IR.
  * - FuncType: type of a function.

include/tvm/meta_schedule/builder.h

@@ -40,7 +40,7 @@ class BuilderInputNode : public runtime::Object {
   IRModule mod;
   /*! \brief The target to be built for. */
   Target target;
-  /*! \brief Parameters for Relay build module. */
+  /*! \brief Parameters for Relax build module. */
   Optional<Map<String, runtime::NDArray>> params;
 
   void VisitAttrs(tvm::AttrVisitor* v) {
@@ -63,7 +63,7 @@ class BuilderInput : public runtime::ObjectRef {
    * \brief Constructor of BuilderInput.
    * \param mod The IRModule to be built.
    * \param target The target to be built for.
-   * \param params Parameters for Relay build module.
+   * \param params Parameters for Relax build module.
    */
   TVM_DLL explicit BuilderInput(IRModule mod, Target target,
                                 Optional<Map<String, runtime::NDArray>> params = NullOpt);

include/tvm/target/virtual_device.h

@@ -58,7 +58,7 @@ constexpr int kInvalidDeviceType = -1;
  * \brief Describes at compile time the constraints on where data is to be stored at runtime
  * down to the (virtual) device and memory scope level, and how to compile code to compute that
  * data. Used by the \p PlanDevices pass to collect and solve (virtual) device constraints for
- * the whole Relay program.
+ * the whole Relax program.
  *
  * Is a quadruple of:
  * - A \p device_type (\p DLDeviceType). May be \p kInvalidDeviceType if unconstrained.
@@ -79,7 +79,7 @@ constexpr int kInvalidDeviceType = -1;
  * then the function body is also executed on that device.
  *
  *
- * By 'execution' we include both (fused) primitive operators, and all the Relay expressions
+ * By 'execution' we include both (fused) primitive operators, and all the Relax expressions
  * surrounding them which coordinates data and control flow. Again, typically non-primitive
  * operators must be executed on a 'CPU'-like device with good support for control flow.
  *

include/tvm/topi/transform.h

@@ -775,7 +775,7 @@ inline Tensor dynamic_strided_slice(const Tensor& x, const Array<PrimExpr>& begi
 
   arith::Analyzer analyzer;
   for (size_t i = 0; i < num_slice_axes; ++i) {
-    // Check ProducerLoad to keep backward compatibility for Relay.
+    // Check ProducerLoad to keep backward compatibility for Relax.
     if (!begin[i]->IsInstance<ProducerLoadNode>() && !end[i]->IsInstance<ProducerLoadNode>() &&
         !strides[i]->IsInstance<ProducerLoadNode>()) {
       out_shape.push_back(
@@ -840,7 +840,7 @@ inline te::Tensor dynamic_strided_slice(const te::Tensor& x, const te::Tensor& b
 }
 
 /*!
- * \brief Calculate the output shape of strided_slice, the entry point for Relay type relation
+ * \brief Calculate the output shape of strided_slice, the entry point for Relax type relation
  *
  * \param ishape The input tensor shape
  * \param begin The indices to begin with in the slicing

python/gen_requirements.py

@@ -26,9 +26,9 @@
 TVM can be roughly broken into these named pieces along the lines of Python dependencies:
 
 - "core": A core piece, which is intended to be buildable with very few external dependencies. Users
-  can use Relay, compile models, and run autotuning with this part.
+  can use Relax, compile models, and run autotuning with this part.
 - "importer-<tool>": Model importers, which convert models defined in various other tools (i.e.
-  TensorFlow, PyTorch, etc) into Relay models.
+  TensorFlow, PyTorch, etc) into Relax models.
 - Extra features (i.e. XGBoost in AutoTVM). These enhance TVM's functionality, but aren't required
   for basic operation.
 
@@ -74,7 +74,7 @@
             ],
         ),
     ),
-    # Relay frontends.
+    # frontends.
     ("importer-coreml", ("Requirements for the CoreML importer", ["coremltools"])),
     (
         "importer-keras",

python/setup.py

@@ -206,11 +206,6 @@ def is_pure(self):
     setup_kwargs = {"include_package_data": True}
 
 
-def get_package_data_files():
-    # Relay standard libraries
-    return []
-
-
 def long_description_contents():
     with open(pathlib.Path(CURRENT_DIR).resolve().parent / "README.md", encoding="utf-8") as readme:
         description = readme.read()
@@ -255,7 +250,6 @@ def long_description_contents():
     extras_require=extras_require,
     packages=find_packages(),
     package_dir={"tvm": "tvm"},
-    package_data={"tvm": get_package_data_files()},
     distclass=BinaryDistribution,
     ext_modules=config_cython(),
     **setup_kwargs,

python/tvm/__init__.py

@@ -66,7 +66,7 @@
 # Contrib initializers
 from .contrib import rocm as _rocm, nvcc as _nvcc
 
-# Relay and Relax contain modules that are only available in compiler package
+# Relax contain modules that are only available in compiler package
 # Do not import them if TVM is built with runtime only
 if not _RUNTIME_ONLY:
     from . import relax

python/tvm/contrib/cutlass/build.py

@@ -15,7 +15,7 @@
 # specific language governing permissions and limitations
 # under the License.
 # pylint: disable=invalid-name, dangerous-default-value, arguments-differ
-"""Driver for partitioning and building a Relay module for CUTLASS offload."""
+"""Driver for partitioning and building a Relax module for CUTLASS offload."""
 import itertools
 import logging
 import multiprocessing
@@ -298,7 +298,7 @@ def tune_cutlass_kernels(
     Parameters
     ----------
     mod : IRModule
-        The Relay module with cutlass partitions.
+        The IRModule with cutlass partitions.
 
     sm : int
         An integer specifying the compute capability. For example, 75 for Turing and

python/tvm/contrib/mrvl.py

@@ -208,7 +208,7 @@ def get_nodes_json_string(graph_json):
 
 @tvm._ffi.register_func("tvm.mrvl.ModifyConstNames")
 def modify_const_names(nodes_json_str, consts_json_str):
-    """This takes the graph module returned by relay.build an generates nodes and constant
+    """This takes the graph module returned by build an generates nodes and constant
        meta data suitable for compilation by the back end.
 
     Parameters