|
| 1 | +ITT annotations support |
| 2 | +======================= |
| 3 | + |
| 4 | +This extension enables a set of functions implementing |
| 5 | +the Instrumentation and Tracing Technology (ITT) functionality |
| 6 | +in SYCL device code. |
| 7 | + |
| 8 | +There are three sets of functions defined by this extension, |
| 9 | +and they serve different purposes. |
| 10 | + |
| 11 | +User APIs |
| 12 | +--------- |
| 13 | + |
| 14 | +The user code calling these functions must include the corresponding header |
| 15 | +file(s) provided by `ittnotify` project (TBD: reference ITT repo here). |
| 16 | + |
| 17 | +These functions are named using `__itt_notify_` prefix. |
| 18 | + |
| 19 | +Stub APIs |
| 20 | +--------- |
| 21 | + |
| 22 | +These functions are not defined in any header file, and their declarations |
| 23 | +follow exactly the declarations of the corresponding user APIs, except that |
| 24 | +they have an extra `_stub` suffix in their names. |
| 25 | + |
| 26 | +These functions implement the ITT functionality in a way that allows |
| 27 | +the tools, such as Intel(R) Inspector, to recognize the ITT annotations |
| 28 | +and run their analysis methods based on that. |
| 29 | + |
| 30 | +For SYCL device code these functions are implemented as `noinline` and `optnone` |
| 31 | +functions so that the corresponding calls may be distinguished in the execution |
| 32 | +trace. This is just one way for implementing them, and the actual implementation |
| 33 | +may change in future. |
| 34 | + |
| 35 | +Compiler wrapper APIs |
| 36 | +--------------------- |
| 37 | + |
| 38 | +These functions are not defined in any header file, and they are supposed |
| 39 | +to be called from the compiler generated code. These thin wrappers |
| 40 | +just provide a convenient way for compilers to produce ITT annotations |
| 41 | +without generating too much code in the compilers' IR. |
| 42 | + |
| 43 | +These functions have `_wrapper` suffix in their names. |
| 44 | + |
| 45 | +Example |
| 46 | +~~~~~~~ |
| 47 | + |
| 48 | +.. code: c++ |
| 49 | + DEVICE_EXTERN_C void __itt_offload_wi_start_stub( |
| 50 | + size_t[3], size_t, uint32_t); |
| 51 | +
|
| 52 | + DEVICE_EXTERN_C void __itt_offload_wi_start_wrapper() { |
| 53 | + if (__spirv_SpecConstant(0xFF747469, 0)) { |
| 54 | + size_t GroupID[3] = ...; |
| 55 | + size_t WIId = ...; |
| 56 | + uint32_t WGSize = ...; |
| 57 | + __itt_offload_wi_start_stub(GroupID, WIId, WGSize); |
| 58 | + } |
| 59 | + } |
| 60 | +
|
| 61 | +A compiler may generate a simple call to `__itt_offload_wi_start_wrapper` |
| 62 | +to annotate a kernel entry point. Compare this to the code inside the wrapper |
| 63 | +function, which a compiler would have to generate if there were no such |
| 64 | +a wrapper. |
| 65 | + |
| 66 | +Conditional compilation |
| 67 | +----------------------- |
| 68 | + |
| 69 | +To minimize the effect of ITT annotations on the performance of the device code, |
| 70 | +the implementation is guarded with a specialization constant check. This allows |
| 71 | +users and tools to have one version of the annotated code that may be built |
| 72 | +with and without ITT annotations "enabled". When the ITT annotations are not |
| 73 | +enabled, we expect that the overall effect of the annotations will be minimized |
| 74 | +by the dead code elimination optimization(s) made by the device compilers. |
| 75 | + |
| 76 | +For this purpose we reserve a 1-byte specialization constant numbered |
| 77 | +`4285822057` (`0xFF747469`). The users/tools/runtimes should set this |
| 78 | +specialization constant to non-zero value to enable the ITT annotations |
| 79 | +in SYCL device code. |
0 commit comments