[llvm] [OpenMP][Offload] Handle non-memberof `present/to/from` entries irrespective of order. (PR #165494)

Robert Imschweiler via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 30 13:39:43 PDT 2025


ro-i wrote:

> Another alternative is to sort the entries in the runtime, which may be slower than on-demand lookups/updates that this PR does, because we always would be doing this sorting even when not needed, but may be faster in others where the constant-time overhead of map/set insertions/lookups becomes too large because of the number of maps. But that will still have to worry about the from + delete case.

I thought that the re-ordering may be an equivalent but simpler approach. But I think that it may not be. The issue for target *entry*, for example:
- My solution just pushed all "from" mappers to the end of the list and left the other mappers as they are. This solved the conflicts between separate to- and from-mappers, but we would still have conflicts between alloc- and to-mappers as shown by your tests.
- Trying to pull all "to" mappers to the front of the list, and leave the other mappers as they are, would be even worse.
While this would solve the conflicts between separate to- and from-mappers, it would potentially even *add new* conflicts between alloc- and to-mappers. When we have e.g. `map(alloc: a[0:4]) map(to: a[1])`, it is imperative that the larger map is performed first. So, we cannot just pull to-mappers to the start of the list without further analysis.

It's questionable if the re-ordering approach is still simpler if we need to check for overlapping memory.

https://github.com/llvm/llvm-project/pull/165494


More information about the llvm-commits mailing list