[flang-commits] [flang] [Flang][OpenMP] Implement "promotion" of use_device_ptr non-cptr arguments to use_device_addr (PR #82834)

[via flang-commits]

================
@@ -745,6 +797,20 @@ genDataOp(Fortran::lower::AbstractConverter &converter,
                          useDeviceSymbols);
   cp.processUseDeviceAddr(deviceAddrOperands, useDeviceTypes, useDeviceLocs,
                           useDeviceSymbols);
+  // This function implements the deprecated functionality of use_device_ptr
+  // that allows users to provide non-CPTR arguments to it with the caveat
+  // that the compiler will treat them as use_device_addr. A lot of legacy
+  // code may still depend on this functionality, so we should support it
+  // in some manner. We do so currently by simply shifting non-cptr operands
+  // from the use_device_ptr list into the front of the use_device_addr list
+  // whilst maintaining the ordering of useDeviceLocs, useDeviceSymbols and
+  // useDeviceTypes to use_device_ptr/use_device_addr input for BlockArg
+  // ordering.
+  // TODO: Perhaps create a user provideable compiler option that will
+  // re-introduce a hard-error rather than a warning in these cases.
+  promoteNonCPtrUseDevicePtrArgsToUseDeviceAddr(
+      devicePtrOperands, deviceAddrOperands, useDeviceTypes, useDeviceLocs,
+      useDeviceSymbols);
----------------
agozillon wrote:

Tried to make the adjustments suggested, in this case I opted to just keep the one overload of `processUseDevicePtr `but with the extra optional argument (although, happy to add a secondary overload if you'd prefer). I did however, keep the ordering of `processUseDevicePtr`/`processUseDeviceAddr `calls, the most important thing is keeping the `BlockArg `<-> `UseDevicePtr`/`UseDeviceAddr `ordering I believe.

The alternative method I wanted to attempt, didn't work out quite as well as I desired, I believe it'd work but would require seperate vectors for the locs/syms/types for device ptr and addr and a few more optional parameters for each of these for `processUseDevicePtr`. We'd get rid of the  `promoteNonCPtrUseDevicePtrArgsToUseDeviceAddr` from this PR and instead do the "promotion" inside of addUseDeviceClause when the optional arguments are present (effectively, if optional arguements are present, check if a type is a cptr, if it isn't move it into the optional arguments which would be the use_device_addr vectors). I stopped digging into it any further to see what the input on the current iteration was and see if you'd prefer this other method I am suggesting!

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