[flang-commits] [flang] Skip POINTER components in implicit mapper generation (PR #177848)

[via flang-commits]

agozillon wrote:

That consistently crashes for me (as I'd expect) on AMDGPU giving:

Display only launched kernel:
Kernel 'omp target in _QQmain @ 16 (__omp_offloading_10306_6003fbf__QQmain_l16)'
OFFLOAD ERROR: memory access fault by GPU 1 (agent 0xf5e810) at virtual address 0x1253000. Reasons: Unknown (0)
Use 'OFFLOAD_TRACK_ALLOCATION_TRACES=true' to track device allocations

Using the following compilation command on a Flang compiled yesterday/early morning in the EU timezone (it's a nightly build of upstream so not one I've built by hand, I can test that myself a little later):

flang -fopenmp --offload-arch=gfx90a test.f90 -o test.out

Have you tried setting the environment variable to OFFLOAD_MANDATORY=1 (e.g. OFFLOAD_MANDATORY=1 ./test.out) to see if you are actively running on a GPU (or some other device), if it is using host fallback mode it will yield very different results at times, as the fallback mode still needs a lot of work with regards to correctness. It is worth noting that on a unified shared memory system it may also behave a little differently.

Otherwise, the FIR emission (that I have butchered, so hopefully it's still readable) for this is:

```
// Our map of obj containing the pointer, has no explicit member map of pointer, will just copy the top-layer for the descriptor

%36 = omp.map.info var_ptr(%10 : !fir.ref<!fir.type<_QFTdt{p:!fir.box<!fir.ptr<!fir.array<?xf32>>>}>>, !fir.type<_QFTdt{p:!fir.box<!fir.ptr<!fir.array<?xf32>>>}>) map_clauses(to) capture(ByRef) name("obj") -> !fir.ref<!fir.type<_QFTdt{p:!fir.box<!fir.ptr<!fir.array<?xf32>>>}>>

// bounds for arr, needed for us to know how much elements are in the array to transfer across, noticeably another thing missing from our map of obj

%42 = omp.map.bounds lower_bound(%c0 : index) upper_bound(%41 : index) extent(%40#1 : index) stride(%40#2 : index) start_idx(%39#0 : index) stride_in_bytes(true)

// maps for our allocatable arr, a descriptor map, data map and then an attach to bind them together, if we change the map of obj to be something like map(obj, obj%p) we'd end up with something like the bounds above and maps below for p

%44 = omp.map.info var_ptr(%4 : !fir.ref<!fir.box<!fir.heap<!fir.array<?xf32>>>>, !fir.box<!fir.heap<!fir.array<?xf32>>>) map_clauses(tofrom) capture(ByRef) var_ptr_ptr(%43 : !fir.llvm_ptr<!fir.ref<!fir.array<?xf32>>>, f32) bounds(%42) name("") -> !fir.llvm_ptr<!fir.ref<!fir.array<?xf32>>>
%45 = omp.map.info var_ptr(%4 : !fir.ref<!fir.box<!fir.heap<!fir.array<?xf32>>>>, !fir.box<!fir.heap<!fir.array<?xf32>>>) map_clauses(always, to) capture(ByRef) members(%44 : [0] : !fir.llvm_ptr<!fir.ref<!fir.array<?xf32>>>) name("arr") -> !fir.ref<!fir.box<!fir.heap<!fir.array<?xf32>>>>
%46 = omp.map.info var_ptr(%4 : !fir.ref<!fir.box<!fir.heap<!fir.array<?xf32>>>>, !fir.box<!fir.heap<!fir.array<?xf32>>>) map_clauses(attach, ref_ptr, ref_ptee) capture(ByRef) var_ptr_ptr(%43 : !fir.llvm_ptr<!fir.ref<!fir.array<?xf32>>>, f32) bounds(%42) name("arr") -> !fir.ref<!fir.box<!fir.heap<!fir.array<?xf32>>>>
 
// map for scalar i, which the runtime is smart enough to firstprivatize, although, might be do-able a bit more optimally still in the future
%47 = omp.map.info var_ptr(%6 : !fir.ref<i32>, i32) map_clauses(implicit) capture(ByCopy) name("i") -> !fir.ref<i32>
 
omp.target kernel_type(spmd) host_eval(%c1_i32 -> %arg0, %c10_i32 -> %arg1, %c1_i32 -> %arg2 : i32, i32, i32) map_entries(%36 -> %arg3, %45 -> %arg4, %47 -> %arg5, %46 -> %arg6, %44 -> %arg7 : !fir.ref<!fir.type<_QFTdt{p:!fir.box<!fir.ptr<!fir.array<?xf32>>>}>>, !fir.ref<!fir.box<!fir.heap<!fir.array<?xf32>>>>, !fir.ref<i32>, !fir.ref<!fir.box<!fir.heap<!fir.array<?xf32>>>>, !fir.llvm_ptr<!fir.ref<!fir.array<?xf32>>>) {
```

There was an case for an erroneous (not quite an error, just excessive map generation) mapper generation until last week though, but it would have been unlikely to impact this particular test I believe (and there is no spurious mapper generated in the current MLIR).


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