[flang-commits] [flang] [Flang][OpenMP] Align map clause generation and fix issue with non-shared allocations for assumed shape/size descriptor types (PR #97855)

[via flang-commits]

================
@@ -970,25 +970,21 @@ bool ClauseProcessor::processMap(
                   object.ref(), clauseLocation, asFortran, bounds,
                   treatIndexAsSection);
 
-          auto origSymbol = converter.getSymbolAddress(*object.sym());
-          mlir::Value symAddr = info.addr;
-          if (origSymbol && fir::isTypeWithDescriptor(origSymbol.getType()))
-            symAddr = origSymbol;
-
           // Explicit map captures are captured ByRef by default,
           // optimisation passes may alter this to ByCopy or other capture
           // types to optimise
+          mlir::Value baseOp = info.rawInput;
----------------
agozillon wrote:

@jeanPerier @tblah I am not the most familiar with HLFIR (or FIR) yet unfortunately, however, I was interested in knowing if there was any possible side effects of utilising the memref/input from a HLFIR declare operation as opposed to the other possible result which seems to carry more information?

I believe, at least for the moment, we don't need the extra information provided by the HLFIR DeclareOp's other result from my (possibly flawed) understanding, As we already generate and carry the bounds around as part of the MapInfoOp, and we don't need any further information it currently provides from what I can tell. The main benefit of utilising the rawInput (result 1, of the declare op when there, otherwise just the symbol adcress) is it simplifies the maps we generate in certain scenarios as we end up processing less BoxTypes (as in certain cases, the HLFIR declare op's result 0 provides the more complex to map BoxType as opposed to the simpler original input type, presumably to help carry more information).

Essentially wondering if utilising the rawInput in all cases (at least that we currently handle) seems reasonable and sane from a FIR/HLFIR perspective. If we ever required the more complex result, it would be possible to do so, just with a slight extra layer of complexity to the lowering and a (likely mild) performance hit from extra mappings in certain cases.

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