|
| 1 | +%\pagebreak |
| 2 | +\section{Self Mapping} |
| 3 | +\label{sec:self_mapping} |
| 4 | + |
| 5 | +\index{self maps} |
| 6 | + |
| 7 | +In general, a map operation may create a separate copy of a list item in a |
| 8 | +device data environment that the runtime implementation must associate with the |
| 9 | +original list item. A \emph{self map} is a map operation that does not result in a |
| 10 | +separate copy of a list item. Rather, the original storage of the list item is |
| 11 | +reused for the device data environment, with the runtime regarding its storage |
| 12 | +as being ``mapped'' to itself. |
| 13 | + |
| 14 | +OpenMP 6.0 adds the \kcode{self} modifier to the \kcode{map} clause to require |
| 15 | +that its list items are mapped using a self map. The \kcode{self} keyword was |
| 16 | +also added as an argument to the \kcode{defaultmap} clause, indicating that |
| 17 | +variables of a specified category in a \kcode{target} construct are self mapped |
| 18 | +by default. Additionally, the \kcode{self_maps} clause was added to the |
| 19 | +\kcode{requires} directive to require that all map operations in a given |
| 20 | +compilation unit should be self maps. The \kcode{self_maps} clause includes all |
| 21 | +the guarantees provided by the \kcode{unified_shared_memory} requirement clause. |
| 22 | + |
| 23 | +The following C example shows the use of these features when mapping a structure |
| 24 | +type to a device. The self map allows \ucode{start} and \ucode{end} pointer |
| 25 | +data members that point to the start and end of the \ucode{buf} data member to |
| 26 | +be used on the device without requiring pointer attachments. |
| 27 | + |
| 28 | +\cexample[6.0]{self_map}{1} |
| 29 | + |
| 30 | +The next C++ and Fortran example maps a structure for which an array member |
| 31 | +\ucode{buf} is private but may be accessed in the public interface via a |
| 32 | +pointer member \ucode{p}. When mapping the structure to a device, the |
| 33 | +programmer must ordinarily ensure that the \ucode{p} data member on the device |
| 34 | +is attached to the \ucode{buf} data member, by adding a \ucode{my_data.p[:]} |
| 35 | +(for C++) or \ucode{my_data\%p(:)} (for Fortran) list item to a \kcode{map} |
| 36 | +clause. By instead asking for the structure to be self mapped, there is no need |
| 37 | +for the pointer attachment. |
| 38 | + |
| 39 | +\cppexample[6.0]{self_map}{2} |
| 40 | +\ffreeexample[6.0]{self_map}{2} |
| 41 | + |
| 42 | +If the implementation is unable to satisfy the requirements of a self map then |
| 43 | +a runtime error will be issued. This may occur because the original storage is |
| 44 | +not accessible and cannot be made accessible from the device, or it may occur |
| 45 | +because the storage has already been mapped to the device without a self map. A |
| 46 | +third case is that the self map applies to a pointer for which pointer |
| 47 | +attachment is prescribed to a pointee that was not also self mapped. Since a |
| 48 | +self-mapped attached pointer in that case would assign a device address to the |
| 49 | +original pointer which would almost certainly not be the desired behavior. |
| 50 | + |
| 51 | +The following example illustrates each of the three cases above that could |
| 52 | +potentially result in a runtime error due to an unfulfilled self map. |
| 53 | + |
| 54 | +\cexample[6.0]{self_map}{3} |
| 55 | +\ffreeexample[6.0]{self_map}{3} |
| 56 | + |
0 commit comments