///
/// Copyright (c) 2017-2021 Arm Limited.
///
/// SPDX-License-Identifier: MIT
///
/// Permission is hereby granted, free of charge, to any person obtaining a copy
/// of this software and associated documentation files (the "Software"), to
/// deal in the Software without restriction, including without limitation the
/// rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
/// sell copies of the Software, and to permit persons to whom the Software is
/// furnished to do so, subject to the following conditions:
///
/// The above copyright notice and this permission notice shall be included in all
/// copies or substantial portions of the Software.
///
/// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
/// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
/// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
/// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
/// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
/// OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
/// SOFTWARE.
///
namespace arm_compute
{
/** @page how_to_build How to Build and Run Examples

@tableofcontents

@section S1_1_build_options Build options

scons 2.3 or above is required to build the library.
To see the build options available simply run ```scons -h```:

        debug: Debug (yes|no)
            default: False

        asserts: Enable asserts (this flag is forced to 1 for debug=1) (yes|no)
            default: False

        logging: Logging (this flag is forced to 1 for debug=1) (yes|no)
            default: False

        arch: Target Architecture (armv7a|arm64-v8a|arm64-v8.2-a|arm64-v8.2-a-sve|arm64-v8.2-a-sve2|x86_32|x86_64|armv8a|armv8.2-a|armv8.2-a-sve|armv8.6-a|armv8.6-a-sve|armv8.6-a-sve2|armv8r64|x86)
            default: armv7a

        estate: Execution State (auto|32|64)
            default: auto

        os: Target OS (linux|android|macos|tizen|bare_metal)
            default: linux

        build: Build type (native|cross_compile|embed_only)
            default: cross_compile

        examples: Build example programs (yes|no)
            default: True

        gemm_tuner: Build gemm_tuner programs (yes|no)
            default: True

        Werror: Enable/disable the -Werror compilation flag (yes|no)
            default: True

        standalone: Builds the tests as standalone executables, links statically with libgcc, libstdc++ and libarm_compute (yes|no)
            default: False

        opencl: Enable OpenCL support (yes|no)
            default: True

        neon: Enable Arm® Neon™ support (yes|no)
            default: False

        embed_kernels: Embed OpenCL kernels in library binary (yes|no)
            default: True

        compress_kernels: Compress embedded OpenCL kernels in library binary. Note embed_kernels should be enabled as well (yes|no)
            default: False

        set_soname: Set the library's soname and shlibversion (requires SCons 2.4 or above) (yes|no)
            default: False

        openmp: Enable OpenMP backend (yes|no)
            default: False

        cppthreads: Enable C++11 threads backend (yes|no)
            default: True

        build_dir: Specify sub-folder for the build ( /path/to/build_dir )
            default: .

        install_dir: Specify sub-folder for the install ( /path/to/install_dir )
            default:

        exceptions: Enable/disable C++ exception support (yes|no)
            default: True

        linker_script: Use an external linker script ( /path/to/linker_script )
            default:

        custom_options: Custom options that can be used to turn on/off features
            (all|none|comma-separated list of names)
            allowed names: disable_mmla_fp
            default: none

        data_type_support: Enable a list of data types to support
            (all|none|comma-separated list of names)
            allowed names: qasymm8 qasymm8_signed qsymm16 fp16 fp32
            default: all

        toolchain_prefix: Override the toolchain prefix
            default:

        compiler_prefix: Override the compiler prefix
            default:

        extra_cxx_flags: Extra CXX flags to be appended to the build command
            default:

        extra_link_flags: Extra LD flags to be appended to the build command
            default:

        compiler_cache: Command to prefix to the C and C++ compiler (e.g ccache)
            default:

        specs_file: Specs file to use
            default: rdimon.specs

        benchmark_examples: Build benchmark examples programs (yes|no)
            default: False

        validate_examples: Build validate examples programs (yes|no)
            default: False

        reference_openmp: Build reference validation with openmp (yes|no)
            default: True

        validation_tests: Build validation test programs (yes|no)
            default: False

        benchmark_tests: Build benchmark test programs (yes|no)
            default: False

        test_filter: Pattern to specify the tests' filenames to be compiled
            default: *.cpp

        pmu: Enable PMU counters (yes|no)
            default: False

        mali: Enable Arm® Mali™ hardware counters (yes|no)
            default: False

        external_tests_dir: Add examples, benchmarks and tests to the tests suite from an external path ( /path/to/external_tests_dir )
            default:

        high_priority: Generate a library using only the high priority operators
            default: False

        data_layout_support: Enable a list of data layout to support
            default: False

@b debug / @b asserts:
 - With debug=1 asserts are enabled, and the library is built with symbols and no optimisations enabled.
 - With debug=0 and asserts=1: Optimisations are enabled and symbols are removed, however all the asserts are still present (This is about 20% slower than the release build)
 - With debug=0 and asserts=0: All optimisations are enable and no validation is performed, if the application misuses the library it is likely to result in a crash. (Only use this mode once you are sure your application is working as expected).

@b arch: The x86_32 and x86_64 targets can only be used with neon=0 and opencl=1.

@b os: Choose the operating system you are targeting: Linux, Android or bare metal.
@note bare metal can only be used for Arm® Neon™ (not OpenCL), only static libraries get built and Neon™'s multi-threading support is disabled.

@b build: you can either build directly on your device (native) or cross compile from your desktop machine (cross-compile). In both cases make sure the compiler is available in your path.

@note If you want to natively compile for 32bit on a 64bit Arm device running a 64bit OS then you will have to use cross-compile too.

There is also an 'embed_only' option which will generate all the .embed files for the OpenCL kernels. This might be useful if using a different build system to compile the library.

In addition the option 'compress_kernels' will compress the embedded OpenCL kernel files using zlib and inject them in the library. This is useful for reducing the binary size. Note, this option is only available for Android when 'embed_kernels' is enabled.

@b Werror: If you are compiling using the same toolchains as the ones used in this guide then there shouldn't be any warning and therefore you should be able to keep Werror=1. If with a different compiler version the library fails to build because of warnings interpreted as errors then, if you are sure the warnings are not important, you might want to try to build with Werror=0 (But please do report the issue on Github).

@b opencl / @b neon: Choose which SIMD technology you want to target. (Neon™ for Arm® Cortex®-A CPUs or OpenCL for Arm® Mali™ GPUs)

@b embed_kernels: For OpenCL only: set embed_kernels=1 if you want the OpenCL kernels to be built in the library's binaries instead of being read from separate ".cl" / ".cs" files. If embed_kernels is set to 0 then the application can set the path to the folder containing the OpenCL kernel files by calling CLKernelLibrary::init(). By default the path is set to "./cl_kernels".

@b set_soname: Do you want to build the versioned version of the library ?

If enabled the library will contain a SONAME and SHLIBVERSION and some symlinks will automatically be created between the objects.
Example:
  libarm_compute_core.so -> libarm_compute_core.so.1.0.0
  libarm_compute_core.so.1 -> libarm_compute_core.so.1.0.0
  libarm_compute_core.so.1.0.0

@note This options is disabled by default as it requires SCons version 2.4 or above.

@b extra_cxx_flags: Custom CXX flags which will be appended to the end of the build command.

@b build_dir: Build the library in a subfolder of the "build" folder. (Allows to build several configurations in parallel).

@b examples: Build or not the examples

@b validation_tests: Enable the build of the validation suite.

@b benchmark_tests: Enable the build of the benchmark tests

@b pmu: Enable the PMU cycle counter to measure execution time in benchmark tests. (Your device needs to support it)

@b mali: Enable the collection of Arm® Mali™ hardware counters to measure execution time in benchmark tests. (Your device needs to have a Arm® Mali™ driver that supports it)

@b openmp: Build in the OpenMP scheduler for Neon™.

@note Only works when building with g++ not clang++

@b cppthreads: Build in the C++11 scheduler for Neon™.

@sa Scheduler::set

@b external_tests_dir: Add examples, benchmarks and tests to the tests suite from an external path ( /path/to/external_tests_dir )

In order to use this option, the external tests directory must have the following structure:

    EXTERNAL_TESTS_DIR:
    └── tests
        ├── benchmark
        │   ├── CL
        │   ├── datasets
        │   ├── fixtures
        │   └── Neon
        └── validation
            ├── CL
            ├── datasets
            ├── fixtures
            └── Neon

Then, build the library with `external_tests_dir=<PATH_TO_EXTERNAL_TESTS_DIR>`.

@b high_priority: Generate a library using only the high priority operators

@b data_layout_support: Enable a list of data layout to support

@section S1_2_linux Building for Linux

@subsection S1_2_1_library How to build the library ?

For Linux, the library was successfully built and tested using the following Linaro GCC toolchain:

 - gcc-linaro-6.3.1-2017.05-x86_64_arm-linux-gnueabihf
 - gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu

To cross-compile the library in debug mode, with Arm® Neon™ only support, for Linux 32bit:

	scons Werror=1 -j8 debug=1 neon=1 opencl=0 os=linux arch=armv7a

To cross-compile the library in asserts mode, with OpenCL only support, for Linux 64bit:

	scons Werror=1 -j8 debug=0 asserts=1 neon=0 opencl=1 embed_kernels=1 os=linux arch=arm64-v8a

You can also compile the library natively on an Arm device by using <b>build=native</b>:

	scons Werror=1 -j8 debug=0 neon=1 opencl=0 os=linux arch=arm64-v8a build=native
	scons Werror=1 -j8 debug=0 neon=1 opencl=0 os=linux arch=armv7a build=native

@note g++ for Arm is mono-arch, therefore if you want to compile for Linux 32bit on a Linux 64bit platform you will have to use a cross compiler.

For example on a 64bit Debian based system you would have to install <b>g++-arm-linux-gnueabihf</b>

	apt-get install g++-arm-linux-gnueabihf

Then run

	scons Werror=1 -j8 debug=0 neon=1 opencl=0 os=linux arch=armv7a build=cross_compile

or simply remove the build parameter as build=cross_compile is the default value:

	scons Werror=1 -j8 debug=0 neon=1 opencl=0 os=linux arch=armv7a

@subsection S1_2_2_examples How to manually build the examples ?

The examples get automatically built by scons as part of the build process of the library described above. This section just describes how you can build and link your own application against our library.

@note The following command lines assume the arm_compute libraries are present in the current directory or in the system library path. If this is not the case you can specify the location of the pre-built libraries with the compiler option -L. When building the OpenCL example the commands below assume that the CL headers are located in the include folder where the command is executed.

To cross compile a Arm® Neon™ example for Linux 32bit:

	arm-linux-gnueabihf-g++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -mfpu=neon -L. -larm_compute -larm_compute_core -o neon_cnn

To cross compile a Arm® Neon™ example for Linux 64bit:

	aarch64-linux-gnu-g++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -L. -larm_compute -larm_compute_core -o neon_cnn

(notice the only difference with the 32 bit command is that we don't need the -mfpu option and the compiler's name is different)

To cross compile an OpenCL example for Linux 32bit:

	arm-linux-gnueabihf-g++ examples/cl_sgemm.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -mfpu=neon -L. -larm_compute -larm_compute_core -o cl_sgemm -DARM_COMPUTE_CL

To cross compile an OpenCL example for Linux 64bit:

	aarch64-linux-gnu-g++ examples/cl_sgemm.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -L. -larm_compute -larm_compute_core -o cl_sgemm -DARM_COMPUTE_CL

(notice the only difference with the 32 bit command is that we don't need the -mfpu option and the compiler's name is different)

To cross compile the examples with the Graph API, such as graph_lenet.cpp, you need to link the examples against arm_compute_graph.so too.

i.e. to cross compile the "graph_lenet" example for Linux 32bit:

	arm-linux-gnueabihf-g++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -mfpu=neon -L. -larm_compute_graph -larm_compute -larm_compute_core -Wl,--allow-shlib-undefined -o graph_lenet

i.e. to cross compile the "graph_lenet" example for Linux 64bit:

	aarch64-linux-gnu-g++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -L. -larm_compute_graph -larm_compute -larm_compute_core -Wl,--allow-shlib-undefined -o graph_lenet

(notice the only difference with the 32 bit command is that we don't need the -mfpu option and the compiler's name is different)

@note If compiling using static libraries, this order must be followed when linking: arm_compute_graph_static, arm_compute, arm_compute_core

To compile natively (i.e directly on an Arm device) for Arm® Neon™ for Linux 32bit:

	g++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -mfpu=neon -larm_compute -larm_compute_core -o neon_cnn

To compile natively (i.e directly on an Arm device) for Arm® Neon™ for Linux 64bit:

	g++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute -larm_compute_core -o neon_cnn

(notice the only difference with the 32 bit command is that we don't need the -mfpu option)

To compile natively (i.e directly on an Arm device) for OpenCL for Linux 32bit or Linux 64bit:

	g++ examples/cl_sgemm.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute -larm_compute_core -o cl_sgemm -DARM_COMPUTE_CL

To compile natively the examples with the Graph API, such as graph_lenet.cpp, you need to link the examples against arm_compute_graph.so too.

i.e. to natively compile the "graph_lenet" example for Linux 32bit:

	g++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -mfpu=neon -L. -larm_compute_graph -larm_compute -larm_compute_core -Wl,--allow-shlib-undefined -o graph_lenet

i.e. to natively compile the "graph_lenet" example for Linux 64bit:

	g++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -L. -larm_compute_graph -larm_compute -larm_compute_core -Wl,--allow-shlib-undefined -o graph_lenet

(notice the only difference with the 32 bit command is that we don't need the -mfpu option)

@note If compiling using static libraries, this order must be followed when linking: arm_compute_graph_static, arm_compute, arm_compute_core

@note These two commands assume libarm_compute.so is available in your library path, if not add the path to it using -L (e.g. -Llib/linux-arm64-v8a-neon-cl-asserts/)
@note You might need to export the path to OpenCL library as well in your LD_LIBRARY_PATH if Compute Library was built with OpenCL enabled.

To run the built executable simply run:

	LD_LIBRARY_PATH=build ./neon_cnn

or

	LD_LIBRARY_PATH=build ./cl_sgemm

@note Examples accept different types of arguments, to find out what they are run the example with \a --help as an argument. If no arguments are specified then random values will be used to execute the graph.

For example:

	LD_LIBRARY_PATH=. ./graph_lenet --help

Below is a list of the common parameters among the graph examples :
@snippet utils/CommonGraphOptions.h Common graph examples parameters

@subsection S1_2_3_sve Build for SVE or SVE2

In order to build for SVE or SVE2 you need a compiler that supports them. You can find more information in the following these links:
    -# GCC: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/sve-support
    -# LLVM: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/llvm-toolchain/sve-support

@note You the need to indicate the toolchains using the scons "toolchain_prefix" parameter.

An example build command with SVE is:

        scons arch=arm64-v8.2-a-sve os=linux build_dir=arm64 -j55 standalone=0 opencl=0 openmp=0 validation_tests=1 neon=1 cppthreads=1 toolchain_prefix=aarch64-none-linux-gnu-

@section S1_3_android Building for Android

For Android, the library was successfully built and tested using Google's standalone toolchains:
 - clang++ from NDK r18b for armv7a
 - clang++ from NDK r20b for arm64-v8a
 - clang++ from NDK r20b for arm64-v8.2-a with FP16 support

For NDK r18 or older, here is a guide to <a href="https://developer.android.com/ndk/guides/standalone_toolchain.html">create your Android standalone toolchains from the NDK</a>:
- Download the NDK r18b from here: https://developer.android.com/ndk/downloads/index.html to directory $NDK
- Make sure you have Python 2.7 installed on your machine.
- Generate the 32 and/or 64 toolchains by running the following commands to your toolchain directory $MY_TOOLCHAINS:

	$NDK/build/tools/make_standalone_toolchain.py --arch arm64 --install-dir $MY_TOOLCHAINS/aarch64-linux-android-ndk-r18b --stl libc++ --api 21
	$NDK/build/tools/make_standalone_toolchain.py --arch arm --install-dir $MY_TOOLCHAINS/arm-linux-android-ndk-r18b --stl libc++ --api 21

For NDK r19 or newer, you can directly <a href="https://developer.android.com/ndk/downloads">Download</a> the NDK package for your development platform, without the need to launch the make_standalone_toolchain.py script. You can find all the prebuilt binaries inside $NDK/toolchains/llvm/prebuilt/$OS_ARCH/bin/.
@attention the building script will look for a binary named "aarch64-linux-android-clang++", while the prebuilt binaries will have their API version as a suffix to their filename (e.g. "aarch64-linux-android21-clang++"). You should copy/rename the binary removing this suffix, or - alternatively - create an alias for it.

@attention We used to use gnustl but as of NDK r17 it is deprecated so we switched to libc++

@note Make sure to add the toolchains to your PATH:

	export PATH=$PATH:$MY_TOOLCHAINS/aarch64-linux-android-ndk-r18b/bin:$MY_TOOLCHAINS/arm-linux-android-ndk-r18b/bin

@subsection S1_3_1_library How to build the library ?

To cross-compile the library in debug mode, with Arm® Neon™ only support, for Android 32bit:

	CXX=clang++ CC=clang scons Werror=1 -j8 debug=1 neon=1 opencl=0 os=android arch=armv7a

To cross-compile the library in asserts mode, with OpenCL only support, for Android 64bit:

	CXX=clang++ CC=clang scons Werror=1 -j8 debug=0 asserts=1 neon=0 opencl=1 embed_kernels=1 os=android arch=arm64-v8a

@subsection S1_3_2_examples How to manually build the examples ?

The examples get automatically built by scons as part of the build process of the library described above. This section just describes how you can build and link your own application against our library.

@note The following command lines assume the arm_compute libraries are present in the current directory or in the system library path. If this is not the case you can specify the location of the pre-built libraries with the compiler option -L. When building the OpenCL example the commands below assume that the CL headers are located in the include folder where the command is executed.

Once you've got your Android standalone toolchain built and added to your path you can do the following:

To cross compile a Arm® Neon™ example:

	#32 bit:
	arm-linux-androideabi-clang++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -larm_compute_core-static -L. -o neon_cnn_arm -static-libstdc++ -pie
	#64 bit:
	aarch64-linux-android-clang++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -larm_compute_core-static -L. -o neon_cnn_aarch64 -static-libstdc++ -pie

To cross compile an OpenCL example:

	#32 bit:
	arm-linux-androideabi-clang++ examples/cl_sgemm.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -larm_compute_core-static -L. -o cl_sgemm_arm -static-libstdc++ -pie -DARM_COMPUTE_CL
	#64 bit:
	aarch64-linux-android-clang++ examples/cl_sgemm.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -larm_compute_core-static -L. -o cl_sgemm_aarch64 -static-libstdc++ -pie -DARM_COMPUTE_CL

To cross compile the examples with the Graph API, such as graph_lenet.cpp, you need to link the library arm_compute_graph also.

	#32 bit:
	arm-linux-androideabi-clang++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -Wl,--whole-archive -larm_compute_graph-static -Wl,--no-whole-archive -larm_compute-static -larm_compute_core-static -L. -o graph_lenet_arm -static-libstdc++ -pie -DARM_COMPUTE_CL
	#64 bit:
	aarch64-linux-android-clang++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -Wl,--whole-archive -larm_compute_graph-static -Wl,--no-whole-archive -larm_compute-static -larm_compute_core-static -L. -o graph_lenet_aarch64 -static-libstdc++ -pie -DARM_COMPUTE_CL

@note Due to some issues in older versions of the Arm® Mali™ OpenCL DDK (<= r13p0), we recommend to link arm_compute statically on Android.
@note When linked statically the arm_compute_graph library currently needs the --whole-archive linker flag in order to work properly

Then you need to do is upload the executable and the shared library to the device using ADB:

	adb push neon_cnn_arm /data/local/tmp/
	adb push cl_sgemm_arm /data/local/tmp/
	adb push gc_absdiff_arm /data/local/tmp/
	adb shell chmod 777 -R /data/local/tmp/

And finally to run the example:

	adb shell /data/local/tmp/neon_cnn_arm
	adb shell /data/local/tmp/cl_sgemm_arm
	adb shell /data/local/tmp/gc_absdiff_arm

For 64bit:

	adb push neon_cnn_aarch64 /data/local/tmp/
	adb push cl_sgemm_aarch64 /data/local/tmp/
	adb push gc_absdiff_aarch64 /data/local/tmp/
	adb shell chmod 777 -R /data/local/tmp/

And finally to run the example:

	adb shell /data/local/tmp/neon_cnn_aarch64
	adb shell /data/local/tmp/cl_sgemm_aarch64
	adb shell /data/local/tmp/gc_absdiff_aarch64

@note Examples accept different types of arguments, to find out what they are run the example with \a --help as an argument. If no arguments are specified then random values will be used to execute the graph.

For example:
	adb shell /data/local/tmp/graph_lenet --help

In this case the first argument of LeNet (like all the graph examples) is the target (i.e 0 to run on Neon™, 1 to run on OpenCL if available, 2 to run on OpenCL using the CLTuner), the second argument is the path to the folder containing the npy files for the weights and finally the third argument is the number of batches to run.

@section S1_4_macos Building for macOS

The library was successfully natively built for Apple Silicon under macOS 11.1 using clang v12.0.0.

To natively compile the library with accelerated CPU support:

	scons Werror=1 -j8 neon=1 opencl=0 os=macos arch=arm64-v8a build=native

@note Initial support disables feature discovery through HWCAPS and thread scheduling affinity controls

@section S1_5_bare_metal Building for bare metal

For bare metal, the library was successfully built using linaro's latest (gcc-linaro-6.3.1-2017.05) bare metal toolchains:
 - arm-eabi for armv7a
 - aarch64-elf for arm64-v8a

Download linaro for <a href="https://releases.linaro.org/components/toolchain/binaries/6.3-2017.05/arm-eabi/">armv7a</a> and <a href="https://releases.linaro.org/components/toolchain/binaries/6.3-2017.05/aarch64-elf/">arm64-v8a</a>.

@note Make sure to add the toolchains to your PATH: export PATH=$PATH:$MY_TOOLCHAINS/gcc-linaro-6.3.1-2017.05-x86_64_aarch64-elf/bin:$MY_TOOLCHAINS/gcc-linaro-6.3.1-2017.05-x86_64_arm-eabi/bin

@subsection S1_5_1_library How to build the library ?

To cross-compile the library with Arm® Neon™ support for baremetal arm64-v8a:

	scons Werror=1 -j8 debug=0 neon=1 opencl=0 os=bare_metal arch=arm64-v8a build=cross_compile cppthreads=0 openmp=0 standalone=1

@subsection S1_5_2_examples How to manually build the examples ?

Examples are disabled when building for bare metal. If you want to build the examples you need to provide a custom bootcode depending on the target architecture and link against the compute library. More information about bare metal bootcode can be found <a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0527a/index.html">here</a>.

@section S1_6_windows_host Building on a Windows host system

Using `scons` directly from the Windows command line is known to cause
problems. The reason seems to be that if `scons` is setup for cross-compilation
it gets confused about Windows style paths (using backslashes). Thus it is
recommended to follow one of the options outlined below.

@subsection S1_6_1_ubuntu_on_windows Bash on Ubuntu on Windows

The best and easiest option is to use
<a href="https://msdn.microsoft.com/en-gb/commandline/wsl/about">Ubuntu on Windows</a>.
This feature is still marked as *beta* and thus might not be available.
However, if it is building the library is as simple as opening a *Bash on
Ubuntu on Windows* shell and following the general guidelines given above.

@subsection S1_6_2_cygwin Cygwin

If the Windows subsystem for Linux is not available <a href="https://www.cygwin.com/">Cygwin</a>
can be used to install and run `scons`, the minimum Cygwin version must be 3.0.7 or later. In addition
to the default packages installed by Cygwin `scons` has to be selected in the installer. (`git` might
also be useful but is not strictly required if you already have got the source
code of the library.) Linaro provides pre-built versions of
<a href="http://releases.linaro.org/components/toolchain/binaries/">GCC cross-compilers</a>
that can be used from the Cygwin terminal. When building for Android the
compiler is included in the Android standalone toolchain. After everything has
been set up in the Cygwin terminal the general guide on building the library
can be followed.

@section S1_7_cl_requirements OpenCL DDK Requirements

@subsection S1_7_1_cl_hard_requirements Hard Requirements

Compute Library requires OpenCL 1.1 and above with support of non uniform workgroup sizes, which is officially supported in the Arm® Mali™ OpenCL DDK r8p0 and above as an extension (respective extension flag is \a -cl-arm-non-uniform-work-group-size).

Enabling 16-bit floating point calculations require \a cl_khr_fp16 extension to be supported. All Arm® Mali™ GPUs with compute capabilities have native support for half precision floating points.

@subsection S1_7_2_cl_performance_requirements Performance improvements

Integer dot product built-in function extensions (and therefore optimized kernels) are available with Arm® Mali™ OpenCL DDK r22p0 and above for the following GPUs : G71, G76. The relevant extensions are \a cl_arm_integer_dot_product_int8, \a cl_arm_integer_dot_product_accumulate_int8 and \a cl_arm_integer_dot_product_accumulate_int16.

OpenCL kernel level debugging can be simplified with the use of printf, this requires the \a cl_arm_printf extension to be supported.

SVM allocations are supported for all the underlying allocations in Compute Library. To enable this OpenCL 2.0 and above is a requirement.

*/
} // namespace arm_compute