[PATCH] D152554: [OpenMP] Migrate deviice code privatization from Clang CodeGen to OMPIRBuilder

Johannes Doerfert via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jun 29 13:26:13 PDT 2023


jdoerfert added a comment.

typo in the title.



================
Comment at: clang/lib/CodeGen/CGOpenMPRuntime.h:1444
+    /// alloca address where the runtime returns the device pointers.
+    llvm::DenseMap<const ValueDecl *, llvm::Value *> CaptureDeviceAddrMap;
   };
----------------
If it is an alloca (for sure) use `llvm::AllocaInst`.


================
Comment at: clang/test/OpenMP/target_data_use_device_ptr_codegen.cpp:418
-    // CK2:     [[VAL1:%.+]] = load ptr, ptr [[BP1]],
-    // CK2:     store ptr [[VAL1]], ptr [[PVT1:%.+]],
     // CK2:     store ptr [[PVT1]], ptr [[_PVT1:%.+]],
----------------
Did we just change the order or is this non-deterministic? The latter is not acceptable, the former might be.


================
Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:4131
+      for (auto DeviceMap : Info.DevicePtrInfoMap) {
+        if (isa<AllocaInst>(DeviceMap.second.second)) {
+          auto *LI =
----------------
What else could it be here?


================
Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:4694
+      } else if (CombinedInfo.DevicePointers[I] == DeviceInfoTy::Address) {
+        Info.DevicePtrInfoMap[BPVal] = {BP, BP};
+        assert(DeviceAddrCB &&
----------------
What if the PointerBCOrASCast and the GEP are both no-ops, and BPVal is an alloca. Would that cause a problem as we later only check if the type of the value is an alloca. That said, it seems dangerous to only rely on the type of the value.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D152554/new/

https://reviews.llvm.org/D152554



More information about the cfe-commits mailing list