[Docs] Update links and fix typos in docs and readme (apache#7965)

docs/dev/index.rst

@@ -27,7 +27,7 @@ This page is organized as follows:
 - The `Logical Architecture Components`_ section describes the logical components.
   The sections after are specific guides focused on each logical component, organized
   by the component's name.
-- Feel free to also checkout the :ref:`dev-how-to` for useful development tips.
+- Feel free to also check out the :ref:`dev-how-to` for useful development tips.
 
 This guide provides a few complementary views of the architecture.
 First, we review a single end-to-end compilation flow and discuss the key data structures and the transformations.
@@ -42,7 +42,7 @@ In this guide, we will study an example compilation flow in the compiler. The fi
 
 - Import: The frontend component ingests a model into an IRModule, which contains a collection of functions that internally represent the model.
 - Transformation: The compiler transforms an IRModule to another functionally equivalent or approximately
-  equivalent(e.g. in the case of quantization) IRModule. Many of the transformatons are target (backend) independent.
+  equivalent(e.g. in the case of quantization) IRModule. Many of the transformations are target (backend) independent.
   We also allow target to affect the configuration of the transformation pipeline.
 - Target Translation: The compiler translates(codegen) the IRModule to an executable format specified by the target.
   The target translation result is encapsulated as a `runtime.Module` that can be exported, loaded, and executed on the target runtime environment.
@@ -103,7 +103,7 @@ Many low-level optimizations can be handled in the target phase by the LLVM, CUD
 Search-space and Learning-based Transformations
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The transformation passes we described so far are deterministic and rule-based. One design goal of the TVM stack is to support high-performance code optimizations for different hardware platforms. To do so, we will need to investigate as many optimizations choices as possible, including but not limited to, multi-dimensional tensor access, loop tiling behavior, special accelerator memory hierarchy, and threading.
+The transformation passes we described so far are deterministic and rule-based. One design goal of the TVM stack is to support high-performance code optimizations for different hardware platforms. To do so, we will need to investigate as many optimization choices as possible, including but not limited to, multi-dimensional tensor access, loop tiling behavior, special accelerator memory hierarchy, and threading.
 
 It is hard to define a heuristic to make all of the choices. Instead, we will take a search and learning-based approach.
 We first define a collection of actions we can take to transform a program. Example actions include loop transformations, inlining,

docs/dev/pass_infra.rst

@@ -394,7 +394,7 @@ Python Frontend
 
 Only some simple APIs are needed for the frontend side. For example, we can
 provide users the following APIs to create and execute a pass (full
-implementation is provided in `python/tvm/relay/transform.py`_ and
+implementation is provided in `python/tvm/relay/transform/transform.py`_ and
 `python/tvm/ir/transform.py`_). The backend
 receives the information and decides which function it should use to create
 a Pass object.
@@ -460,7 +460,7 @@ users so that they can customize their own pass or pass pipeline.
 
 For all the passes that are implemented in the C++ backend, we provide
 corresponding Python APIs in `python/tvm/ir/transform.py`_ and
-`python/tvm/relay/transform.py`_, respectively. For instance,
+`python/tvm/relay/transform/transform.py`_, respectively. For instance,
 const folding has a Python API like the following:
 
 .. code:: python
@@ -538,7 +538,7 @@ optimization pipeline and debug Relay and tir passes, please refer to the
 
 .. _src/relay/pass/fold_constant.cc: https://github.com/apache/tvm/blob/main/src/relay/pass/fold_constant.cc
 
-.. _python/tvm/relay/transform.py: https://github.com/apache/tvm/blob/main/python/tvm/relay/transform.py
+.. _python/tvm/relay/transform/transform.py: https://github.com/apache/tvm/blob/main/python/tvm/relay/transform/transform.py
 
 .. _include/tvm/relay/transform.h: https://github.com/apache/tvm/blob/main/include/tvm/relay/transform.h
 

docs/dev/runtime.rst

@@ -138,11 +138,9 @@ This philosophy of embedded API is very like Lua, except that we don't have a ne
 
 One fun fact about PackedFunc is that we use it for both compiler and deployment stack.
 
-- All compiler pass functions of TVM are exposed to frontend as PackedFunc, see `here`_
+- All compiler pass functions of TVM are exposed to frontend as PackedFunc
 - The compiled module also returns the compiled function as PackedFunc
 
-.. _here: https://github.com/apache/tvm/tree/main/src/api
-
 To keep the runtime minimum, we isolated the IR Object support from the deployment runtime. The resulting runtime takes around 200K - 600K depending on how many runtime driver modules (e.g., CUDA) get included.
 
 The overhead of calling into PackedFunc vs. a normal function is small, as it is only saving a few values on the stack.
@@ -279,7 +277,7 @@ Each argument in PackedFunc contains a union value `TVMValue`_
 and a type code. This design allows the dynamically typed language to convert to the corresponding type directly, and statically typed language to
 do runtime type checking during conversion.
 
-.. _TVMValue: https://github.com/apache/tvm/blob/main/include/tvm/runtime/c_runtime_api.h#L122
+.. _TVMValue: https://github.com/apache/tvm/blob/main/include/tvm/runtime/c_runtime_api.h#L135
 
 The relevant files are
 

src/README.md

@@ -31,5 +31,4 @@ There can be internal header files within each module that sit in src.
 - relay: Relay IR, high-level optimization.
 - autotvm: The auto-tuning module.
 - contrib: Contrib extension libraries.
-- api: API function registration.
 - driver: Compilation driver APIs.