shylie/llvm-project
1
0
Fork 0
Code Issues Pull Requests Actions 6 Packages Projects Releases Wiki Activity
llvm-project/offload/test/offloading/struct_mapping_with_pointers.cpp
Abhinav Gaba 1fbf33cd40
[OpenMP][Clang] Use ATTACH map-type for list-items with base-pointers. (#153683) 
This adds support for using `ATTACH` map-type for proper
pointer-attachment when mapping list-items that have base-pointers.

For example, for the following:

```c
  int *p;
  #pragma omp target enter data map(p[1:10])
```

The following maps are now emitted by clang:
```
  (A)
  &p[0], &p[1], 10 * sizeof(p[1]), TO | FROM
  &p, &p[1], sizeof(p), ATTACH
```

Previously, the two possible maps emitted by clang were:
```
  (B)
  &p[0], &p[1], 10 * sizeof(p[1]), TO | FROM

  (C)
  &p, &p[1], 10 * sizeof(p[1]), TO | FROM | PTR_AND_OBJ
````

(B) does not perform any pointer attachment, while (C) also maps the
pointer p, both of which are incorrect.

-----

With this change, we are using ATTACH-style maps, like `(A)`, for cases
where the expression has a base-pointer. For example:


```cpp
  int *p, **pp;
  S *ps, **pps;
  ... map(p[0])
  ... map(p[10:20])
  ... map(*p)
  ... map(([20])p)
  ... map(ps->a)
  ... map(pps->p->a)
  ... map(pp[0][0])
  ... map(*(pp + 10)[0])

```

#### Grouping of maps based on attach base-pointers
We also group mapping of clauses with the same base decl in the order of
the increasing complexity of their base-pointers, e.g. for something
like:
```
  S **spp;
  map(spp[0][0], spp[0][0].a), // attach-ptr: spp[0]
  map(spp[0]),                 // attach-ptr: spp
  map(spp),                    // attach-ptr: N/A
```

We first map `spp`, then `spp[0]` then `spp[0][0]` and `spp[0][0].a`.

This allows us to also group "struct" allocation based on their attach
pointers. This resolves the issues of us always mapping everything from
the beginning of the symbol `spp`. Each group is mapped independently,
and at the same level, like `spp[0][0]` and its member `spp[0][0].a`, we
still get map them together as part of the same contiguous struct
`spp[0][0]`. This resolves issue #141042.

#### use_device_ptr/addr fixes
The handling of `use_device_ptr/addr` was updated to use the attach-ptr
information, and works for many cases that were failing before. It has
to be done as part of this series because otherwise, the switch from
ptr_to_obj to attach-style mapping would have caused regressions in
existing use_device_ptr/addr tests.

#### Handling of attach-pointers that are members of implicitly mapped
structs:
* When a struct member-pointer, like `p` below, is a base-pointer in a
`map` clause on a target construct (like `map(p[0:1])`, and the base of
that struct is either the `this` pointer (implicitly or explicitly), or
a struct that is implicitly mapped on that construct, we add an implicit
`map(p)` so that we don't implicitly map the full struct.
 ```c
  struct S { int *p;
  void f1() {
    #pragma omp target map(p[0:1]) // Implicitly map this->p, to ensure
// that the implicit map of `this[:]` does
                                   // not map the full struct
       printf("%p %p\n", &p, p);
  }
 ```

#### Scope for improvement:
* We may be able to compute attach-ptr expr while collecting
component-lists in Sema.
* But we cache the computation results already, and `findAttachPtrExpr`
is fairly simple, and fast.
* There may be a better way to implement semantic expr comparison.

#### Needs future work:
* Attach-style maps not yet emitted for declare mappers.
* Mapping of class member references: We are still using PTR_AND_OBJ
maps for them. We will likely need to change that to handle
`ref_ptr/ref_ptee`, and `attach` map-type-modifier on them.
* Implicit capturing of "this" needs to map the full `this[0:1]` unless
there is an explicit map on one of the members, or a map with a member
as its base-pointer.
* Implicit map added for capturing a class member pointer needs to also
add a zero-length-array-section map.
* `use_device_addr` on array-sections-on-pointers need further
improvements (documented using FIXMEs)

#### Why a large PR
While it's unfortunate that this PR has gotten large and difficult to
review, the issue is that all the functional changes have to be made
together, to prevent regressions from partially implemented changes.

For example, the changes to capturing were previously done separately
(#145454), but they would still cause stability issues in absence of
full attach-mapping. And attach-mapping needs those changes to be able
to launch kernels.

We extracted the utilities and functions, like those for finding
attach-ptrs, or comparing exprs, out as a separate NFC PR that doesn't
call those functions, just adds them (#155625). Maybe the change that
adds a new error message for use_device_addr on array-sections with
non-var base-pointers could have been extracted out too (but that would
have had to be a follow-up change in that case, and we would get
comp-fails with this PR when the erroneous case was not
caught/diagnosed).

---------

Co-authored-by: Alex Duran <alejandro.duran@intel.com>
2025-12-15 16:40:31 -08:00

141 lines
7.1 KiB
C++
Raw Blame History

// clang-format off
// RUN: %libomptarget-compilexx-generic && env LIBOMPTARGET_DEBUG=1 %libomptarget-run-generic 2>&1 | %fcheck-generic
// clang-format on
// REQUIRES: libomptarget-debug
// UNSUPPORTED: nvptx64-nvidia-cuda
// UNSUPPORTED: nvptx64-nvidia-cuda-LTO
#include <stdio.h>
#include <stdlib.h>
struct Descriptor {
int *datum;
long int x;
int *more_datum;
int xi;
int val_datum, val_more_datum;
long int arr[1][30];
int val_arr;
};
int main() {
Descriptor dat = Descriptor();
dat.datum = (int *)malloc(sizeof(int) * 10);
dat.more_datum = (int *)malloc(sizeof(int) * 20);
dat.xi = 3;
dat.arr[0][0] = 1;
dat.datum[7] = 7;
dat.more_datum[17] = 17;
dat.datum[dat.arr[0][0]] = 0;
/// The struct is mapped with type 0x0 when the pointer fields are mapped.
/// The struct is also map explicitly by the user. The second mapping by
/// the user must not overwrite the mapping set up for the pointer fields
/// when mapping the struct happens after the mapping of the pointers.
// clang-format off
// CHECK: omptarget --> Entry 0: Base=0x{{0*}}[[DAT_HST_PTR_BASE:.*]], Begin=0x{{0*}}[[DAT_HST_PTR_BASE]], Size=288, Type=0x{{0*}}1, Name=unknown
// CHECK: omptarget --> Entry 1: Base=0x{{0*}}[[DATUM_HST_PTEE_BASE:.*]], Begin=0x{{0*}}[[DATUM_HST_PTEE_BASE]], Size=40, Type=0x{{0*}}1, Name=unknown
// CHECK: omptarget --> Entry 2: Base=0x{{0*}}[[DAT_HST_PTR_BASE]], Begin=0x[[DATUM_HST_PTEE_BASE]], Size=8, Type=0x{{0*}}4000, Name=unknown
// CHECK: omptarget --> Entry 3: Base=0x{{0*}}[[MORE_DATUM_HST_PTEE_BASE:.*]], Begin=0x{{0*}}[[MORE_DATUM_HST_PTEE_BASE]], Size=80, Type=0x{{0*}}1, Name=unknown
// CHECK: omptarget --> Entry 4: Base=0x{{0*}}[[MORE_DATUM_HST_PTR_BASE:.*]], Begin=0x{{0*}}[[MORE_DATUM_HST_PTEE_BASE]], Size=8, Type=0x{{0*}}4000, Name=unknown
// clang-format on
/// The struct will be mapped in the same order as the above entries.
/// First argument is the struct itself and it will be mapped once.
// clang-format off
// CHECK: omptarget --> Looking up mapping(HstPtrBegin=0x{{0*}}[[DAT_HST_PTR_BASE]], Size=288)...
// CHECK: PluginInterface --> MemoryManagerTy::allocate: size 288 with host pointer 0x{{0*}}[[DAT_HST_PTR_BASE]].
// CHECK: omptarget --> Creating new map entry with HstPtrBase=0x{{0*}}[[DAT_HST_PTR_BASE]], HstPtrBegin=0x{{0*}}[[DAT_HST_PTR_BASE]], TgtAllocBegin=0x{{0*}}[[DAT_DEVICE_PTR_BASE:.*]], TgtPtrBegin=0x{{0*}}[[DAT_DEVICE_PTR_BASE]], Size=288, DynRefCount=1, HoldRefCount=0, Name=unknown
// CHECK: omptarget --> Moving 288 bytes (hst:0x{{0*}}[[DAT_HST_PTR_BASE]]) -> (tgt:0x{{0*}}[[DAT_DEVICE_PTR_BASE]])
// clang-format on
/// Second argument is dat.datum[ : 10]:
// clang-format off
// CHECK: omptarget --> Looking up mapping(HstPtrBegin=0x{{0*}}[[DATUM_HST_PTEE_BASE]], Size=40)...
// CHECK: PluginInterface --> MemoryManagerTy::allocate: size 40 with host pointer 0x{{0*}}[[DATUM_HST_PTEE_BASE]].
// CHECK: omptarget --> Creating new map entry with HstPtrBase=0x{{0*}}[[DATUM_HST_PTEE_BASE]], HstPtrBegin=0x{{0*}}[[DATUM_HST_PTEE_BASE]], TgtAllocBegin=0x[[DATUM_DEVICE_PTR_BASE:.*]], TgtPtrBegin=0x{{0*}}[[DATUM_DEVICE_PTR_BASE]], Size=40, DynRefCount=1, HoldRefCount=0, Name=unknown
// CHECK: omptarget --> Moving 40 bytes (hst:0x{{0*}}[[DATUM_HST_PTEE_BASE]]) -> (tgt:0x{{0*}}[[DATUM_DEVICE_PTR_BASE]])
// clang-format on
/// Third argument conditionally attaches data.datum -> dat.datum[:]
// CHECK: omptarget --> Deferring ATTACH map-type processing for argument 2
/// Fourth argument is dat.more_datum[ : 10]:
// clang-format off
// CHECK: omptarget --> Looking up mapping(HstPtrBegin=0x{{0*}}[[MORE_DATUM_HST_PTEE_BASE]], Size=80)...
// CHECK: omptarget --> Creating new map entry with HstPtrBase=0x{{0*}}[[MORE_DATUM_HST_PTEE_BASE]], HstPtrBegin=0x{{0*}}[[MORE_DATUM_HST_PTEE_BASE]], TgtAllocBegin=0x{{0*}}[[MORE_DATUM_DEVICE_PTR_BASE:.*]], TgtPtrBegin=0x{{0*}}[[MORE_DATUM_DEVICE_PTR_BASE]], Size=80, DynRefCount=1, HoldRefCount=0, Name=unknown
// CHECK: omptarget --> Moving 80 bytes (hst:0x{{0*}}[[MORE_DATUM_HST_PTEE_BASE]]) -> (tgt:0x{{0*}}[[MORE_DATUM_DEVICE_PTR_BASE]])
// clang-format on
/// Fifth argument conditionally attaches data.more_datum -> dat.more_datum[:]
// clang-format off
// CHECK: omptarget --> Deferring ATTACH map-type processing for argument 4
// clang-format on
/// Attach entries are handled at the end
// clang-format off
// CHECK: omptarget --> Processing 2 deferred ATTACH map entries
// CHECK: omptarget --> Processing ATTACH entry 0: HstPtr=0x{{0*}}[[DAT_HST_PTR_BASE]], HstPteeBegin=0x{{0*}}[[DATUM_HST_PTEE_BASE]], PtrSize=8, MapType=0x{{0*}}4000
// CHECK: omptarget --> Attach pointee 0x{{0*}}[[DATUM_HST_PTEE_BASE]] was newly allocated: yes
// CHECK: omptarget --> Update pointer (0x{{.*}}) -> [0x{{.*}}]
// CHECK: omptarget --> Processing ATTACH entry 1: HstPtr=0x{{0*}}[[MORE_DATUM_HST_PTR_BASE]], HstPteeBegin=0x{{0*}}[[MORE_DATUM_HST_PTEE_BASE]], PtrSize=8, MapType=0x{{0*}}4000
// CHECK: omptarget --> Attach pointee 0x{{0*}}[[MORE_DATUM_HST_PTEE_BASE]] was newly allocated: yes
// CHECK: omptarget --> Update pointer (0x{{.*}}) -> [0x{{.*}}]
// clang-format on
#pragma omp target enter data map(to : dat.datum[ : 10]) \
map(to : dat.more_datum[ : 20]) map(to : dat)
/// Checks induced by having a target region:
// clang-format off
// CHECK: omptarget --> Entry 0: Base=0x{{0*}}[[DAT_HST_PTR_BASE]], Begin=0x{{0*}}[[DAT_HST_PTR_BASE]], Size=288, Type=0x{{0*}}223, Name=unknown
// CHECK: omptarget --> Mapping exists (implicit) with HstPtrBegin=0x{{0*}}[[DAT_HST_PTR_BASE]], TgtPtrBegin=0x{{0*}}[[DAT_DEVICE_PTR_BASE]], Size=288, DynRefCount=2 (incremented), HoldRefCount=0, Name=unknown
// CHECK: omptarget --> Obtained target argument 0x{{0*}}[[DAT_DEVICE_PTR_BASE]] from host pointer 0x{{0*}}[[DAT_HST_PTR_BASE]]
// clang-format on
#pragma omp target
{
dat.xi = 4;
dat.datum[7]++;
dat.more_datum[17]++;
dat.val_datum = dat.datum[7];
dat.val_more_datum = dat.more_datum[17];
dat.datum[dat.arr[0][0]] = dat.xi;
dat.val_arr = dat.datum[dat.arr[0][0]];
}
/// Post-target region checks:
// clang-format off
// CHECK: omptarget --> Mapping exists with HstPtrBegin=0x{{0*}}[[DAT_HST_PTR_BASE]], TgtPtrBegin=0x{{0*}}[[DAT_DEVICE_PTR_BASE]], Size=288, DynRefCount=1 (decremented), HoldRefCount=0
// clang-format on
#pragma omp target exit data map(from : dat)
/// Target data end checks:
// clang-format off
// CHECK: omptarget --> Mapping exists with HstPtrBegin=0x{{0*}}[[DAT_HST_PTR_BASE]], TgtPtrBegin=0x{{0*}}[[DAT_DEVICE_PTR_BASE]], Size=288, DynRefCount=0 (decremented, delayed deletion), HoldRefCount=0
// CHECK: omptarget --> Moving 288 bytes (tgt:0x{{0*}}[[DAT_DEVICE_PTR_BASE]]) -> (hst:0x{{0*}}[[DAT_HST_PTR_BASE]])
// clang-format on
// CHECK: dat.xi = 4
// CHECK: dat.val_datum = 8
// CHECK: dat.val_more_datum = 18
// CHECK: dat.datum[dat.arr[0][0]] = 0
// CHECK: dat.val_arr = 4
printf("dat.xi = %d\n", dat.xi);
printf("dat.val_datum = %d\n", dat.val_datum);
printf("dat.val_more_datum = %d\n", dat.val_more_datum);
printf("dat.datum[dat.arr[0][0]] = %d\n", dat.datum[dat.arr[0][0]]);
printf("dat.val_arr = %d\n", dat.val_arr);
return 0;
}
Reference in New Issue View Git Blame Copy Permalink