Replace Executorch with ExecuTorch (#455)

Summary:
Pull Request resolved: #455

Start with md files first.

codemod -m -d ./ --extensions md 'Executorch' 'ExecuTorch'

Went one-by-one to make sure it is only changing texts (not code examples).

Reviewed By: dbort

Differential Revision: D49550644

fbshipit-source-id: 1bc3eb8670eb90ecf1ebee083415ae6c2524a87a

Author: mergennachin

CONTRIBUTING.md

@@ -113,7 +113,7 @@ must work with threading**
 ## For Delegate Authors
 
 * Use [this](/docs/website/docs/contributors/delegates.md)
-guide when integrating your delegate with Executorch.
+guide when integrating your delegate with ExecuTorch.
 
 * Refer to [this](/docs/website/docs/contributors/delegates_and_dependencies.md)
 set of guidelines when including a 3p depenency for your delegate.

README.md

@@ -39,13 +39,13 @@ Compared to the legacy Lite Interpreter, there are some major benefits:
 
 - [Setting up ExecuTorch from GitHub](/docs/website/docs/tutorials/00_setting_up_executorch.md)
     - (Optional) [Building with CMake](/docs/website/docs/tutorials/cmake_build_system.md)
-- [Exporting to Executorch](/docs/website/docs/tutorials/exporting_to_executorch.md)
+- [Exporting to ExecuTorch](/docs/website/docs/tutorials/exporting_to_executorch.md)
     - [EXIR Spec](/docs/website/docs/ir_spec/00_exir.md)
     - [Exporting manual](/docs/website/docs/export/00_export_manual.md)
     - [Quantization](/docs/website/docs/tutorials/quantization_flow.md)
     - [Delegate to a backend](/docs/website/docs/tutorials/backend_delegate.md)
     - [Profiling](/docs/website/docs/tutorials/profiling.md)
-- [Executorch Google Colab](https://colab.research.google.com/drive/1m8iU4y7CRVelnnolK3ThS2l2gBo7QnAP#scrollTo=1o2t3LlYJQY5)
+- [ExecuTorch Google Colab](https://colab.research.google.com/drive/1m8iU4y7CRVelnnolK3ThS2l2gBo7QnAP#scrollTo=1o2t3LlYJQY5)
 
 ## Directory Structure [WIP]
 
@@ -67,7 +67,7 @@ executorch
 |   ├── backend                     #  Backend delegate ahead of time APIs
 |   ├── capture                     #  Program capture.
 |   ├── dialects                    #  Op sets for various dialects in the export process.
-|   ├── emit                        #  Conversion from ExportedProgram to Executorch execution instructions.
+|   ├── emit                        #  Conversion from ExportedProgram to ExecuTorch execution instructions.
 |   ├── program                     #  Export artifacts.
 |   ├── serialize                   #  Serialize final export artifact.
 ├── extension                       #  Extensions built on top of the runtime.
@@ -90,7 +90,7 @@ executorch
 |   ├── executor                    #  Model loading, initalization, and execution.
 |   ├── kernel                      #  Kernel registration and management.
 |   ├── platform                    #  Layer between architecture specific code and user calls.
-├── schema                          #  Executorch program definition, TODO move under serialization/
+├── schema                          #  ExecuTorch program definition, TODO move under serialization/
 ├── scripts                         #  Utility scripts for size management, dependency management, etc.
 ├── sdk                             #  Model profiling, debugging, and introspection: NOT READY YET FOR OSS USE
 ├── shim                            #  Compatibility layer between OSS and Internal builds

backends/arm/README.md

@@ -1,6 +1,6 @@
-# Executorch Arm/TOSA Delegate
+# ExecuTorch Arm/TOSA Delegate
 
-This subtree contains the Arm Delegate implementation for Executorch.
+This subtree contains the Arm Delegate implementation for ExecuTorch.
 
 This delegate is structured to, over time, support a number of different Arm devices
 through an AoT flow which targets multiple Arm IP using the TOSA standard.

backends/xnnpack/README.md

@@ -1,6 +1,6 @@
-# Executorch XNNPACK Delegate
+# ExecuTorch XNNPACK Delegate
 
-This subtree contains the XNNPACK Delegate implementation for Executorch.
+This subtree contains the XNNPACK Delegate implementation for ExecuTorch.
 XNNPACK is an optimized library of neural network inference operators for ARM
 and x86 CPUs. It is an open source project used by PyTorch. The delegate is the
 mechanism for leveraging the XNNPACK library to accelerate operators running on

docs/source/compiler-delegate-and-partitioner.md

@@ -251,7 +251,7 @@ with open(save_path, "wb") as f:
 
 ## Runtime
 
-The serialized flatbuffer model is loaded by the Executorch runtime. The
+The serialized flatbuffer model is loaded by the ExecuTorch runtime. The
 preprocessed blob is directly stored in the flatbuffer, which is loaded into a
 call to the backend's `init()` function during model initialization stage. At
 the model execution stage, the initialized handled can be executed through the

docs/website/docs/basics/terminology.md

@@ -12,7 +12,7 @@ along with related types (ScalarType, etc.)
   clients: e.g., CUDA support, sparse tensor support, dtype promotion
 
 ### Portable mode
-Portable mode uses Executorch's smaller `torch::executor::Tensor` (aka ETensor)
+Portable mode uses ExecuTorch's smaller `torch::executor::Tensor` (aka ETensor)
 implementation, along with related types (`torch::executor::ScalarType`, etc.)
 * ETensor's API is a source-compatible subset of `at::Tensor`. Code that is
   written against ETensor can also build against `at::Tensor`.

docs/website/docs/contributors/delegates.md

@@ -1,9 +1,9 @@
-# How to integrate a Backend Delegate with Executorch?
+# How to integrate a Backend Delegate with ExecuTorch?
 
 Disclaimer: We are planning to restructure the repository around delegates.
 With that some of these guidelines will change in the future.
 
-This is a high level guideline when integrating a backend delegate with Executorch.
+This is a high level guideline when integrating a backend delegate with ExecuTorch.
 
 ## Directory Structure
 
@@ -13,9 +13,9 @@ Delegate files should be under this directory:
 ## Python files
 
 Delegate Python files such as one implementing `preprocess()` or `partition()`
-functions for Executorch AoT flow, excluding any external third-party
+functions for ExecuTorch AoT flow, excluding any external third-party
 dependencies and their files, should be installed and available with
-the top level Executorch package. For third-party dependencies, please refer to
+the top level ExecuTorch package. For third-party dependencies, please refer to
 [this](./delegates_and_dependencies.md).
 
 ## C++ sources
@@ -25,13 +25,13 @@ sources.
 
 For the CMake setup, the delegate dir should be included by the
 top level `CMakeLists.txt` file using `add_subdirectory` CMake command, and
-should be built conditionally with an Executorch build flag like
+should be built conditionally with an ExecuTorch build flag like
 `EXECUTORCH_BUILD_<DELEGATE_NAME>`, see `EXECUTORCH_BUILD_XNNPACK` for example.
 For third-party dependencies, please refer to
 [this](./delegates_and_dependencies.md).
 
 Adding buck2 support should make the delegate available to more
-Executorch users.
+ExecuTorch users.
 
 * More details TBD
 

docs/website/docs/contributors/delegates_and_dependencies.md

@@ -21,14 +21,14 @@ Python or C++ dependency. This guide will talk about only Python AoT dependencie
 
 **Guidelines:**
 
-* If Executorch already includes a dependency you require, prefer
+* If ExecuTorch already includes a dependency you require, prefer
   to use that if possible.
 * Since the dependency is only used by the files inside the
   `executorch/backends/<delegate_name>/` - it should introduced in
   a way that it is needed only by the code inside the backend delegate
   directory.
 * The dependency should not be installed by default when installing
-  the Executorch Python package.
+  the ExecuTorch Python package.
 
 More details in the section [below](#python-dependencies).
 
@@ -49,7 +49,7 @@ for these third-party dependencies.
 * If a delegate has a dependency which is already part of
   `executorch/third-party` then try to use that if possible. This
   helps with reducing the binary size when the delegate is enabled.
-* Rest of the Executorch code, outside of the delegate, should not depend on
+* Rest of the ExecuTorch code, outside of the delegate, should not depend on
   this. And it should should build and run correctly without this dependency
   when the delegate is disabled at build time.
 
@@ -64,9 +64,9 @@ the test.
 **Guidelines:**
 
 * For a Python dependency, it should not be installed by default when
-  installing the Executorch Python package.
+  installing the ExecuTorch Python package.
 * If for C++ tests, it should not be part of the
-  Executorch runtime even when the delegate is built/enabled.
+  ExecuTorch runtime even when the delegate is built/enabled.
 
 ## Other considerations
 
@@ -104,10 +104,10 @@ Python packaging is complicated and continuously evolving. For delegate
 dependencies, we recommend that a delegate specifies its third-party
 dependencies under `executorch/backends/<delegate_name>/requirements.txt` to be
 supplied to pip at installation time. The goal is to decouple them from the core
-Executorch dependencies.
+ExecuTorch dependencies.
 
 Version conflict should be avoided by trying to use the already included
-dependency by Executorch or by some other backend if possible. Otherwise
+dependency by ExecuTorch or by some other backend if possible. Otherwise
 try some other
 [recommended](https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts)
 ways to mitigate version conflicts.
@@ -128,7 +128,7 @@ dependency in the `executorch/backends/<delegate_name>/third-party`.
 
 ### buck2/CMake support
 At a minimum CMake support is required. Adding buck2 support should make
-the delegate available to more Executorch users.
+the delegate available to more ExecuTorch users.
 
 * More details TBD
 

docs/website/docs/contributors/design_docs.md

@@ -1,5 +1,5 @@
 # Design Docs
 
-Executorch stack diagram: https://docs.google.com/drawings/d/1bBIbG6YDIjdx8emS_6K23YM6WyRkKVpPt-26nznxroU/edit
+ExecuTorch stack diagram: https://docs.google.com/drawings/d/1bBIbG6YDIjdx8emS_6K23YM6WyRkKVpPt-26nznxroU/edit
 
 High-level design doc: https://docs.google.com/document/d/1Z12w6-KtwoFDh781LQAbfwUdEZw9cwTCmz5BmKuS6U8/edit#

docs/website/docs/contributors/portable_programming.md

@@ -4,7 +4,7 @@ NOTE: This document covers the runtime code: i.e., the code that needs to build
 for and execute in target hardware environments. These rules do not necessarily
 apply to code that only runs on the development host, like authoring tools.
 
-The Executorch runtime code is intendend to be portable, and should build for a
+The ExecuTorch runtime code is intendend to be portable, and should build for a
 wide variety of systems, from servers to mobile phones to DSPs, from POSIX to
 Windows to bare-metal environments.
 
@@ -35,7 +35,7 @@ dependencies except:
 
 ## Platform Abstraction Layer (PAL)
 
-To avoid assuming the capabilities of the target system, the Executorch runtime
+To avoid assuming the capabilities of the target system, the ExecuTorch runtime
 lets clients override low-level functions in its Platform Abstraction Layer
 (PAL), defined in `//executorch/runtime/platform/platform.h`, to perform operations
 like:
@@ -56,7 +56,7 @@ the data already loaded.
 
 ## Integer Types
 
-Executorch runtime code should not assume anything about the sizes of primitive
+ExecuTorch runtime code should not assume anything about the sizes of primitive
 types like `int`, `short`, or `char`. For example, the C++ standard only
 guarantees that `int` will be at least 16 bits wide. And ARM toolchains treat
 `char` as unsigned, while other toolchains often treat it as signed.
@@ -88,7 +88,7 @@ without floating point support.
 ## Logging
 
 Instead of using `printf()`, `fprintf()`, `cout`, `cerr`, or a library like
-`folly::logging` or `glog`, the Executorch runtime provides the `ET_LOG`
+`folly::logging` or `glog`, the ExecuTorch runtime provides the `ET_LOG`
 interface in `//executorch/runtime/platform/log.h` and the `ET_CHECK` interface in
 `//executorch/runtime/platform/assert.h`. The messages are printed using a hook in the PAL,
 which means that clients can redirect them to any underlying logging system, or

docs/website/docs/contributors/program_file_format.md

@@ -1,12 +1,12 @@
 # Program file format
 
-Executorch programs are serialized as modified binary flatbuffer files.
+ExecuTorch programs are serialized as modified binary flatbuffer files.
 
 ```
              ┌───────────────────────────────────┐
              │Standard flatbuffer header         │
              ├───────────────────────────────────┤
-             │Optional Executorch extended header│
+             │Optional ExecuTorch extended header│
              ├───────────────────────────────────┤
              │Flatbuffer-serialized program data │
              │                                   │
@@ -39,7 +39,7 @@ Program files may have an optional extended header at byte offset 8, recognized
 by the magic string beginning with `eh` and followed by two ASCII decimal
 digits. This header includes the size of the flatbuffer-encoded core program
 data, and the starting offset of the segments that may follow the program data.
-Note that this header is Executorch-specific, but even when present it does not
+Note that this header is ExecuTorch-specific, but even when present it does not
 upset most flatbuffer-parsing code (apart from the rarely-used
 `GetBufferStartFromRootPointer()`).
 

docs/website/docs/ir_spec/00_exir.md

@@ -602,7 +602,7 @@ Other permutations of NCHW are allowed but we don’t have explicit names for th
 
 See more on channel_last mem format: [https://pytorch.org/tutorials/intermediate/memory_format_tutorial.html](https://pytorch.org/tutorials/intermediate/memory_format_tutorial.html)
 
-For Executorch, we have introduced a concept of dim orders to convey how a dense tensor is laid out in memory. Tensor's memory layout and memory format representation using the dim order in the Executorch the stack is still a WIP. We will update this doc and the IR spec very shortly.
+For ExecuTorch, we have introduced a concept of dim orders to convey how a dense tensor is laid out in memory. Tensor's memory layout and memory format representation using the dim order in the ExecuTorch the stack is still a WIP. We will update this doc and the IR spec very shortly.
 
 ### Tensor
 A Tensor type describes a mathematical tensor.

docs/website/docs/ir_spec/02_edge_dialect.md

@@ -44,7 +44,7 @@ Default value is true. If set to false, graph validaity check will be turned off
 
 ## Edge Operator
 
-As mentioned before, an edge operator is an ATen core operator with type specialization. This means the instance of edge operator contains a set of dtype constraints, to describe all the tensor dtypes supported by both Executorch runtime and their ATen kernels. These dtype constraints are expressed in a DSL defined in [edge.yaml](https://github.com/pytorch/executorch/blob/main/exir/dialects/edge/edge.yaml). Here's an example of the dtype constraints:
+As mentioned before, an edge operator is an ATen core operator with type specialization. This means the instance of edge operator contains a set of dtype constraints, to describe all the tensor dtypes supported by both ExecuTorch runtime and their ATen kernels. These dtype constraints are expressed in a DSL defined in [edge.yaml](https://github.com/pytorch/executorch/blob/main/exir/dialects/edge/edge.yaml). Here's an example of the dtype constraints:
 
 ```
 - func: sigmoid

docs/website/docs/sdk/05_ETDB.md

@@ -1,6 +1,6 @@
  # Debugging with ETDB
 
-ETDB (Executorch Debugger) is an interactive text-based tool used for investigating models (`ETRecord`) and profiling information (`ETDump`). Features provided include:
+ETDB (ExecuTorch Debugger) is an interactive text-based tool used for investigating models (`ETRecord`) and profiling information (`ETDump`). Features provided include:
 - **Tabular Visualization** of model graphs
 - **Drill-in Selection** of components for detailed investigation
 - **Aggregated Operator Statistics** based on results from ETDump