Developer Guide

FPGA Optimization Guide for Intel® oneAPI Toolkits

ID 767853
Date 12/16/2022
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents

Ignoring Dependencies Between Accessor Arguments

You can direct the Intel® oneAPI DPC++/C++ Compiler to ignore dependencies between accessor arguments in a SYCL* kernel in one of the following methods. Both methods allow the compiler to analyze dependencies between kernel memory operations more accurately, which can result in higher performance.

Method 1: Add the [[intel::kernel_args_restrict]] Attribute to Your Kernel

To direct the Intel® oneAPI DPC++/C++ Compiler to ignore dependencies between accessor arguments and USM pointers used in a kernel, add the [[intel::kernel_args_restrict]] attribute to your kernel. The use of the [[intel::kernel_args_restrict]] attribute is an assurance to the compiler that the accessor arguments and USM pointers used by the kernel do not alias with each other. This is an unchecked assertion by the programmer and results in an undefined behavior if violated.

Example

device_queue.submit([&](handler& cgh) {
  // create accessors from global memory
  accessor in_accessor(in_buf, cgh, read_only);
  accessor out_accessor(out_buf, cgh, write_only);
    
  // run the task (note the use of the attribute here)    
  cgh.single_task<KernelArgsRestrict>([=]() [[intel::kernel_args_restrict]] {
    for (int i = 0; i < N; i++) {
      out_accessor[i] = in_accessor[i];
    }
  });  
});
TIP:

For additional information, refer to the FPGA tutorial sample "Kernel Args Restrict" listed in the Intel® oneAPI Samples Browser on Linux* or Windows*, or access the code sample in GitHub.

Method 2: Add the no_alias Property to an Accessor's Property List

The no_alias property notifies the Intel® oneAPI DPC++/C++ Compiler that all modifications to the memory locations accessed (directly or indirectly) by an accessor during kernel execution is done through the same accessor (directly or indirectly) and not by any other accessor or USM pointer in the kernel. This is an unchecked assertion by the programmer and results in an undefined behavior if it is violated. Effectively, applying no_alias to all accessors of a kernel is equivalent to applying the [[intel::kernel_args_restrict]] attribute to the kernel unless the kernel uses USM. You cannot apply the no_alias property on a USM pointer.

Example

ext::oneapi::accessor_property_list PL{ext::oneapi::no_alias};
accessor acc(buffer, cgh, PL);