[all-commits] [llvm/llvm-project] 1d1c83: Reland "[OpenMP][Offload] Handle `present/to/from`...

[Abhinav Gaba via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1d1c83ad73977a17b06e34243a9b74f41af6da78
      https://github.com/llvm/llvm-project/commit/1d1c83ad73977a17b06e34243a9b74f41af6da78
  Author: Abhinav Gaba <abhinav.gaba at intel.com>
  Date:   2026-03-02 (Mon, 02 Mar 2026)

  Changed paths:
    M offload/include/OpenMP/Mapping.h
    M offload/libomptarget/OpenMP/Mapping.cpp
    M offload/libomptarget/interface.cpp
    M offload/libomptarget/omptarget.cpp
    A offload/test/mapping/map_ordering_ptee_tgt_alloc_mapper_alloc_from_to.c
    A offload/test/mapping/map_ordering_ptee_tgt_data_alloc_tgt_mapper_present_delete_from_to.c
    A offload/test/mapping/map_ordering_tgt_alloc_from_to.c
    A offload/test/mapping/map_ordering_tgt_alloc_present_tofrom.c
    A offload/test/mapping/map_ordering_tgt_alloc_tofrom.c
    A offload/test/mapping/map_ordering_tgt_data_alloc_from.c
    A offload/test/mapping/map_ordering_tgt_data_alloc_to_from.c
    A offload/test/mapping/map_ordering_tgt_data_alloc_tofrom.c
    A offload/test/mapping/map_ordering_tgt_exit_data_always_always.c
    A offload/test/mapping/map_ordering_tgt_exit_data_delete_from.c
    A offload/test/mapping/map_ordering_tgt_exit_data_delete_from_assumedsize.c
    A offload/test/mapping/map_ordering_tgt_exit_data_from_delete_assumedsize.c
    A offload/test/mapping/map_ordering_tgt_exit_data_from_mapper_overlap.c

  Log Message:
  -----------
  Reland "[OpenMP][Offload] Handle `present/to/from` when a different entry did `alloc/delete`." (#184260)

Some tests that were checking for prints inside/outside `target` regions
needed to be updated to work on systems where the ordering wasn't
deterministic.

Reverts llvm/llvm-project#184240
    
Original description from #165494:

-----

OpenMP allows cases like the following:

```c
  int *p1, *p2, x;
  p1 = p2 = &x;
  ...
  #pragma omp target_exit_data map(delete: p1[:]) from(p2[0])
```

Which means, when the runtime encounters the `from` entry, the ref-count
may
not be zero, but it will go down to zero at the end of the current
construct,
which should cause the "from" transfer to happen.

Similarly, a user may have:

```c
  struct S {
    int *p;
  };

  #pragma omp declare_mapper (id1: S s) map(s.p) map(present, alloc: s.p[0:10])
  #pragma omp declare_mapper (id2: S s) map(s.p, s.p[0:10])

  S s1;

 // present-check should fail here
 #pragma omp target_enter_data map(alloc: s.p[0:10]) map(mapper(id1), to: s)
 // "to" should be honored here
 #pragma omp target_enter_data map(alloc: s.p[0:10]) map(mapper(id2), to: s)
```

Where the allocation happens before the "to" entry is encountered by the
runtime. Or, an allocation happens before a "present" entry is
encountered.

To handle cases like this, we need to use the state information of
previously
seen new allocations, deletions, "from" entries, when honoring
`to`/`from`/`present` map entries.

-----



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications