COMPMID-3767: Align documentation with trademark rules

Change-Id: Id2794f2142e21522283a423f0208dc1022036c79
Signed-off-by: Michele Di Giorgio <michele.digiorgio@arm.com>
Reviewed-on: https://review.mlplatform.org/c/ml/ComputeLibrary/+/3942
Reviewed-by: Georgios Pinitas <georgios.pinitas@arm.com>
Comments-Addressed: Arm Jenkins <bsgcomp@arm.com>
Tested-by: Arm Jenkins <bsgcomp@arm.com>

5 files changed, 19 insertions, 19 deletions

diff --git a/arm_compute/runtime/CL/CLTensorAllocator.h b/arm_compute/runtime/CL/CLTensorAllocator.h
index c978dcd92c..067c391489 100644
--- a/arm_compute/runtime/CL/CLTensorAllocator.h
+++ b/arm_compute/runtime/CL/CLTensorAllocator.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2016-2019 Arm Limited.
+ * Copyright (c) 2016-2020 Arm Limited.
  *
  * SPDX-License-Identifier: MIT
  *
@@ -108,7 +108,7 @@ public:
     void free() override;
     /** Import an existing memory as a tensor's backing memory
      *
-     * @warning memory should have been created under the same context that ACL uses.
+     * @warning memory should have been created under the same context that Compute Library uses.
      * @warning memory is expected to be aligned with the device requirements.
      * @warning tensor shouldn't be memory managed.
      * @warning ownership of memory is not transferred.
diff --git a/arm_compute/runtime/NEON/functions/NEGEMMAssemblyDispatch.h b/arm_compute/runtime/NEON/functions/NEGEMMAssemblyDispatch.h
index a82d44fde8..ac77acf69d 100644
--- a/arm_compute/runtime/NEON/functions/NEGEMMAssemblyDispatch.h
+++ b/arm_compute/runtime/NEON/functions/NEGEMMAssemblyDispatch.h
@@ -61,7 +61,7 @@ private:
     MemoryGroup                _memory_group;    /**< Function memory group */
     IWeightsManager           *_weights_manager; /**< Pointer to the weights manager */
 public:
-    /** If supported create an ACL function else fallback to the arm_gemm function.
+    /** If supported create a Compute Library function else fallback to the arm_gemm function.
      *
      * @param[in]  a         Input tensor (Matrix A)
      * @param[in]  b         Input tensor (Matrix B)
diff --git a/docs/00_introduction.dox b/docs/00_introduction.dox
index 0ba1d3ef0b..f8f07906a8 100644
--- a/docs/00_introduction.dox
+++ b/docs/00_introduction.dox
@@ -1670,7 +1670,7 @@ CLTuner looks for the optimal LWS for each unique OpenCL kernel configuration. S
 
 @subsubsection S3_7_1_cl_tuner_how_to How to use it
 
-All the graph examples in the ACL's folder "examples" and the arm_compute_benchmark accept an argument to enable the OpenCL tuner and an argument to export/import the LWS values to/from a file
+All the graph examples in the Compute Library's folder "examples" and the arm_compute_benchmark accept an argument to enable the OpenCL tuner and an argument to export/import the LWS values to/from a file
 
     #Enable CL tuner
     ./graph_mobilenet --enable-tuner –-target=CL
diff --git a/docs/04_adding_operator.dox b/docs/04_adding_operator.dox
index c40aaa3828..cf2e78368d 100644
--- a/docs/04_adding_operator.dox
+++ b/docs/04_adding_operator.dox
@@ -30,7 +30,7 @@ namespace arm_compute
 @tableofcontents
 
 @section S4_1_introduction Introduction
-In ACL there are two main parts or modules:
+In Compute Library there are two main parts or modules:
 - The core library consists of a low-level collection of algorithms implemented in C++ and optimized for Arm CPUs and GPUs. The core module is designed to be embedded in other projects and it doesn't perform any memory management or scheduling.
 - The runtime library is a wrapper of the core library and provides other additional features like memory management, multithreaded execution of workloads and allocation of the intermediate tensors.
 
@@ -41,7 +41,7 @@ Apart from these components that get linked into the application, the sources al
 
 @section S4_1_supporting_new_operators Supporting new operators
 
-Following are the steps involved in adding support for a new operator in ACL
+Following are the steps involved in adding support for a new operator in Compute Library
 - Add new data types (if required)
 - Add the kernel to the core library.
 - Add the function to the runtime library.
@@ -52,7 +52,7 @@ Following are the steps involved in adding support for a new operator in ACL
 
 @subsection S4_1_1_add_datatypes Adding new data types
 
-The ACL declares a few new datatypes related to ACL's domain, kernels, and functions in the library process Tensors and Images (Computer Vision functions). Tensors are multi-dimensional arrays with a maximum of Coordinates::num_max_dimensions dimensions; depending on the number of dimensions tensors can be interpreted as various objects. A scalar can be represented as a zero-dimensional tensor and a vector of numbers can be represented as a one-dimensional tensor. Furthermore, an image is just a 2D tensor, a 3D tensor can be seen as an array of images and a 4D tensor as a 2D array of images, etc.
+Compute Library declares a few new datatypes related to its domain, kernels, and functions in the library process Tensors and Images (Computer Vision functions). Tensors are multi-dimensional arrays with a maximum of Coordinates::num_max_dimensions dimensions; depending on the number of dimensions tensors can be interpreted as various objects. A scalar can be represented as a zero-dimensional tensor and a vector of numbers can be represented as a one-dimensional tensor. Furthermore, an image is just a 2D tensor, a 3D tensor can be seen as an array of images and a 4D tensor as a 2D array of images, etc.
 All the datatype classes or structures are grouped in the core library folder arm_compute/core  like the @ref ITensor, @ref ITensorInfo (all the information of a tensor), TensorShape and simpler types are in arm_compute/core/Types.h.
 
 If an operator handles a new datatype, it must be added to the library. While adding a new data type to the library, it's necessary to implement the function to enable printing, the to_string() method and the output stream insertion (<<) operator. Every datatype implements these two functions in utils/TypePrinter.h
@@ -65,13 +65,13 @@ And for printing:
 
 @snippet utils/TypePrinter.h Print DataLayout type
 
-In the ACL library, we use namespaces to group all the operators, functions, classes and interfaces. The main namespace to use is arm_compute. In the test suite, the test framework and the individual tests use nested namespaces like @ref test::validation or @ref test::benchmark to group the different purposes of various parts of the suite.
+In Compute Library, we use namespaces to group all the operators, functions, classes and interfaces. The main namespace to use is arm_compute. In the test suite, the test framework and the individual tests use nested namespaces like @ref test::validation or @ref test::benchmark to group the different purposes of various parts of the suite.
 Utility functions like conversion or type cast operators, that are shared by multiple operators are in arm_compute/core/Utils.h. Non-inlined function definitions go in the corresponding .cpp files in the src folder.
 Similarly, all common functions that process shapes, like calculating output shapes of an operator or shape conversions etc are in arm_compute/core/utils/misc/ShapeCalculator.h.
 
 
 @subsection S4_1_2_add_kernel Add a kernel
-As we mentioned at the beginning, the kernel is the implementation of the operator or algorithm partially using a specific programming language related to the backend we want to use. Adding a kernel in the library means implementing the algorithm in a SIMD technology like NEON or OpenCL. All kernels in ACL must implement a common interface IKernel or one of the specific subinterfaces.
+As we mentioned at the beginning, the kernel is the implementation of the operator or algorithm partially using a specific programming language related to the backend we want to use. Adding a kernel in the library means implementing the algorithm in a SIMD technology like NEON or OpenCL. All kernels in Compute Library must implement a common interface IKernel or one of the specific subinterfaces.
 IKernel is the common interface for all the kernels in the core library, it contains the main methods for configure and run the kernel itself, such as window()  that return the maximum window the kernel can be executed on or is_parallelisable() for indicate whether or not the kernel is parallelizable. If the kernel is parallelizable then the window returned by the window() method can be split into sub-windows which can then be run in parallel, in the other case, only the window returned by window() can be passed to the run method.
 There are specific interfaces for OpenCL and Neon: @ref ICLKernel, INEKernel (using INEKernel = @ref ICPPKernel).
 
@@ -93,7 +93,7 @@ We must register the new layer in the respective libraries:
 - arm_compute/core/CL/CLKernels.h
 - arm_compute/core/NEON/NEKernels.h
 
-These files contain the list of all kernels available in the corresponding ACL's backend, for example CLKernels:
+These files contain the list of all kernels available in the corresponding Compute Library's backend, for example CLKernels:
 @code{.cpp}
 ... 
 #include "arm_compute/core/CL/kernels/CLMinMaxLayerKernel.h"
@@ -138,7 +138,7 @@ If the tests are already in place, the new kernel can be tested using the existi
 - (sub[n].end() - sub[n].start()) % max[n].step() == 0
 
 @ref CPPScheduler::schedule provides a sample implementation that is used for NEON kernels.
-%Memory management is the other aspect that the runtime layer is supposed to handle. %Memory management of the tensors is abstracted using TensorAllocator. Each tensor holds a pointer to a TensorAllocator object, which is used to allocate and free the memory at runtime. The implementation that is currently supported in ACL allows memory blocks, required to be fulfilled for a given operator, to be grouped together under a @ref MemoryGroup. Each group can be acquired and released. The underlying implementation of memory groups vary depending on whether NEON or CL is used. The memory group class uses memory pool to provide the required memory. It also uses the memory manager to manage the lifetime and a IPoolManager to manage the memory pools registered with the memory manager.
+%Memory management is the other aspect that the runtime layer is supposed to handle. %Memory management of the tensors is abstracted using TensorAllocator. Each tensor holds a pointer to a TensorAllocator object, which is used to allocate and free the memory at runtime. The implementation that is currently supported in Compute Library allows memory blocks, required to be fulfilled for a given operator, to be grouped together under a @ref MemoryGroup. Each group can be acquired and released. The underlying implementation of memory groups vary depending on whether NEON or CL is used. The memory group class uses memory pool to provide the required memory. It also uses the memory manager to manage the lifetime and a IPoolManager to manage the memory pools registered with the memory manager.
 
 
 We have seen the various interfaces for a kernel in the core library, the same structure the same file structure design exists in the runtime module. IFunction is the base class for all the functions, it has two child interfaces: ICLSimpleFunction and INESimpleFunction that are used as base class for functions which call a single kernel.
@@ -268,7 +268,7 @@ The refence implementation consist of two files into the folder tests/validation
 
 where we will put respectively the declaration and definition of the new operator.
 All the utility functions that are used ONLY in the tests are in test/validation/helpers.h, for all the others, as mentioned before, there are helpers in the library.
-ACL and the tests do use templates, the reference implementation is a generic implementation independent from the datatype and we use the templates to generalize the datatype concept.
+Compute Library and the tests do use templates, the reference implementation is a generic implementation independent from the datatype and we use the templates to generalize the datatype concept.
 Following the example, let's have a look at the ReshapeLayer operator:
 
 - tests/validation/reference/ReshapeLayer.h
diff --git a/examples/gemm_tuner/README.md b/examples/gemm_tuner/README.md
index 1effd2f7e1..73bddc9239 100644
--- a/examples/gemm_tuner/README.md
+++ b/examples/gemm_tuner/README.md
@@ -34,7 +34,7 @@ what kernel and subsequently what configurations for that kernels are the most p
 ### Step1: Prepare the shape and configs files
 1. We first need to identify the shapes that we are interested in and store them in a csv file, say *gemm_shapes.csv*.
 2. Then we need to specify a set of good GEMMConfig candidates for each kernel in 3 separate csv files (this requires
-    some prior heuristics, but can be provided by the ACL developers upon requests, based on your target device).
+    some prior heuristics, but can be provided by the Compute Library developers upon requests, based on your target device).
 
    Say we have *gemm_configs_native.csv", "gemm_configs_reshaped.csv" and "gemm_configs_reshaped_only_rhs.csv".
 
@@ -42,9 +42,9 @@ what kernel and subsequently what configurations for that kernels are the most p
 
 ### Step2: Push relevant files to the target device
 All the files that need to be present on the target device are:
-* benchmark script: \<ACL\>/examples/gemm_tuner/benchmark_gemm_examples.sh
+* benchmark script: \<ComputeLibrary\>/examples/gemm_tuner/benchmark_gemm_examples.sh
 * shapes and configs csv files: gemm_shapes.csv, gemm_configs_native.csv, gemm_configs_reshaped_only_rhs.csv, gemm_configs_reshaped.csv
-* Example benchmark binaries: \<ACL\>/build/tests/gemm_tuner/benchmark_cl_gemm*
+* Example benchmark binaries: \<ComputeLibrary\>/build/tests/gemm_tuner/benchmark_cl_gemm*
 
 ### Step3: Collect benchmark data
 With these files on device, we can collect benchmark data using the script. Assume all the example binaries are pushed
@@ -64,7 +64,7 @@ but you may need to change the output folder for each repeat
 1. After benchmarking, we pull the benchmark data, the *results* folder, from the target device to our host machine
 2. We use the GemmTuner.py script to give us the heuristics
    ```
-   python3 <ACL>/examples/gemm_tuner/GemmTuner.py -b ./results -o heuristics
+   python3 <ComputeLibrary>/examples/gemm_tuner/GemmTuner.py -b ./results -o heuristics
    ```
    When it's finished, there should be 4 json files in the *heuristics* folder
 
@@ -76,12 +76,12 @@ passing a lower value to *-t \<tolerance\>* to the GemmTuner.py script.
 * A target device to be tuned, plus the following on the device:
     * Android or Linux OS
     * Bash shell
-    * Built ACL with benchmark examples binaries
+    * Built Compute Library with benchmark examples binaries
     * benchmark_gemm_examples.sh script
     * gemm shape file
 
        A csv file containing the **GEMMParam search list**. This is the list of GEMMParams/gemm shapes that we're
-       interested in (For more details see Approach section). The default list is prepared by ACL developers in advance
+       interested in (For more details see Approach section). The default list is prepared by Compute Library developers in advance
        and can be provided on request.
 
        The format is described as:
@@ -105,7 +105,7 @@ passing a lower value to *-t \<tolerance\>* to the GemmTuner.py script.
     * gemm config file  
       A csv file containing the **GEMMConfig search list**. This is the list of candidate GEMMConfigs among which we
       search for the optimal one. **Note that we have a different list for each strategy.**
-      The default lists are prepared by ACL developers in advance and can be provided on request.
+      The default lists are prepared by Compute Library developers in advance and can be provided on request.
 
       The format of the file for each strategy is the same: