[flang-commits] [flang] [Flang][MLIR] - Access the LEN for a `fir.boxchar<k>` and use it to set the bounds `omp.map.info` ops. (PR #134967)

[Pranav Bhandarkar via flang-commits]

================
@@ -268,8 +274,54 @@ static void bindEntryBlockArgs(lower::AbstractConverter &converter,
                                             cloneBounds(v.getLBounds())));
           },
           [&](const fir::CharBoxValue &v) {
-            converter.bindSymbol(
-                sym, fir::CharBoxValue(arg, cloneBound(v.getLen())));
+            // In some cases, v.len could reference the input to the
+            // hlfir.declare which is the corresponding v.addr. While this isn't
+            // a big problem by itself, it is desirable to extract this out of
+            // v.addr itself since it's first result will be of type
+            // fir.boxchar<>. For example, consider the following
+            //
+            // func.func private @_QFPrealtest(%arg0: !fir.boxchar<1>)
+            //  %2 = fir.dummy_scope : !fir.dscope
+            //  %3:2 = fir.unboxchar %arg0 : (!fir.boxchar<1>) ->
+            //         (!fir.ref<!fir.char<1,?>>, index)
+            //  %4:2 = hlfir.declare (%3#0, %3#1, %2):(!fir.ref<!fir.char<1,?>>,
+            //                        index,!fir.dscope) ->
+            //                       (!fir.boxchar<1>, !fir.ref<!fir.char<1,?>>)
+
+            // In the case above,
+            // v.addr is
+            //  %4:2 = hlfir.declare (%3#0, %3#1, %2):(!fir.ref<!fir.char<1,?>>,
+            //                        index,!fir.dscope) ->
+            //                       (!fir.boxchar<1>, !fir.ref<!fir.char<1,?>>)
+            // v.len is
+            //  %3:2 = fir.unboxchar %arg0 : (!fir.boxchar<1>) ->
+            //         (!fir.ref<!fir.char<1,?>>, index)
+
+            // Mapping this to the target will create a use of %arg0 on the
+            // target. Since omp.target is IsolatedFromAbove, %arg0 will have to
----------------
bhandarkar-pranav wrote:

Since the lower bound `l` is needed in the target OpenMP region in the `hfir.declare` ops for `a0` and `a1`, it is implicitly captured. It is explicitly mapped though because all values used insde the `omp.target` region need to be mapped to incoming block arguments because `omp.target` is `IsolatedFromAbove`. 

The problem in the case that this PR is solving is that this process of creating a temporary for an implicitly captured value is contingent upon such a value having a `definingOp` that is non-null. In the case of block arguments, the definingOp is null.



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