Common Compilation Options

The following table describes common compilation options. For details about all compilation options, see the BiSheng Compiler options.

Option	Required (Yes/No)	Description
-help	No	Displays the help information.
--npu-arch	Yes	Specifies the AI processor architecture for compilation. The value is dav-<arch-version>, where <arch-version> indicates the NPU architecture version number. For details about the architecture version number of each product model, see Table 1.
--npu-soc	No	Specifies the AI processor model for compilation. If both npu-soc and npu-arch are configured, npu-arch is preferentially enabled. The AI processor model can be obtained in the following ways: For the following products: Run the npu-smi info command on the server where AI processor is installed to obtain the Name information. The actual value is AscendName. For example, if Name is xxxyy, the actual value is Ascendxxxyy. Atlas A2 training product / Atlas A2 inference product Atlas 200I/500 A2 inference product Atlas inference product Atlas training product For the Atlas A3 training product / Atlas A3 inference product : Run the npu-smi info -t board -i id -c chip_id command on the server where AI processor is installed to obtain the Chip Name and NPU Name information. The actual value is Chip Name_NPU Name. For example, if the value of Chip Name is Ascendxxx and the value of NPU Name is 1234, the actual value is Ascendxxx_1234. Note that: id: device ID, which is the NPU ID obtained by running the npu-smi info -l command. chip_id: chip ID, which is obtained by running the npu-smi info -m command. For the Atlas 350 Accelerator Card: Run the npu-smi info -t board -i id command on the server where AI processor is installed to obtain the Chip Name and NPU Name information. The actual value is Chip Name_NPU Name. For example, if the value of Chip Name is Ascendxxx and the value of NPU Name is 1234, the actual value is Ascendxxx_1234. id indicates the device ID, which is the NPU ID obtained by running the npu-smi info -l command.
-x	No	Specifies the compilation language. If this parameter is set to asc, the Ascend C programming language is used.
-o <file>	No	Specifies the name and location of the output file.
-c	No	Compiles and generates the target file.
-shared, --shared	No	Compiles and generates a dynamic link library.
-lib, --cce-build-static-lib	No	Compiles and generates a static link library. The compiler compiles and links the code on the device to generate a binary file on the device, uses the file as the input for compilation on the host, and links the file to generate a static link library.
-g	No	Adds debugging information during compilation.
--sanitizer	No	Adds code correctness verification information during compilation. When the sanitizer option is used, the -g option must be added and cannot be used in the -O0 scenario. Note: After this option is enabled, L2 cache is enabled for GlobalTensor by default. You cannot disable L2 cache by calling the AscendC::SetL2CacheHint API.
-fPIC	No	Instructs the compiler to generate location-independent code.
-O	No	Specifies the optimization level of the compiler. Currently, -O3, -O2, and -O0 are supported.
--run-mode=sim	No	SIM mode: During linking, you can add the implementation library corresponding to the simulation mode so that the code can run in simulation mode. You can view simulation-related logs to facilitate performance debugging.

Built-in Compilation Macro Switches

The built-in compilation macro switches are as follows:

ASCENDC_DUMP is used to control the dump switch. By default, the dump switch is enabled. After you call printf/DumpTensor/assert, information is printed. (Note that the host function exists in the kernel file of the launch project. If printf is called in the host function, the printf initialization in the kernel will be triggered, affecting the kernel execution performance.) If this macro is defined as 0, the dump switch is disabled. The following is an example:
```
// Disable the printf printing function of all operators.
ascendc_compile_definitions(ascendc_kernels_${RUN_MODE} PRIVATE
    ASCENDC_DUMP=0
)
```
ASCENDC_DEBUG is used to control the debugging switch of Ascend C APIs. By default, the debugging switch is disabled. After this compilation macro is added, the debugging switch is enabled. In this case, the assert verification inside the API takes effect. If the verification fails, assert logs are printed. Enabling this switch affects the actual running performance of the operator. Therefore, this function is usually used in the debugging phase. The following is an example:
```
ascendc_compile_definitions(ascendc_kernels_${RUN_MODE} PRIVATE
    ASCENDC_DEBUG
)
```
Currently, the ASCENDC_DEBUG function supports the following product models:

Atlas inference product

Atlas A2 training product / Atlas A2 inference product
ENABLE_CV_COMM_VIA_SSBUF is used to control whether to use SSBuffer and the hardware channel from the UB to the L1 buffer. This option is required when CV communication (AIC and AIV) is involved or when data movement APIs are used. Enabling this option can improve the performance of related APIs or unlock additional functions. This option is disabled by default. Setting it to true indicates to enable the switch. The following is an example:
```
ascendc_compile_definitions(ascendc_kernels_${RUN_MODE} PRIVATE
    ENABLE_CV_COMM_VIA_SSBUF=true
)
```
This option is supported only by Atlas 350 Accelerator Card.
- For operators ported from other hardware platforms to this platform, this option is disabled by default to ensure compatibility.
- For operators newly developed on this platform, this option needs to be enabled in the following scenarios: (a) Matmul high-level APIs are used together with APIs such as SetTensorScaleA. These APIs are new functions of Atlas 350 Accelerator Card and use SSBuffer in their internal implementation. (b) The DataCopy API is used to copy data from the UB to the L1 buffer.
NO_OVERLAP_IN_MULTI_REPEAT
This compilation option is used to remove unnecessary memory synchronization instructions when there is no address overlap, thereby improving performance. For the Atlas 350 Accelerator Card, when the high-dimensional sharding computation API of the basic API is used, memory synchronization instructions are inserted by default to ensure data correctness in complex scenarios such as address overlapping. However, these synchronization instructions cause performance overheads. In scenarios where ultimate performance is pursued, this option can be used if you can ensure that no memory overlap occurs in the code under any circumstances.