[PATCH] D11361: [OpenMP] Target directive host codegen

[Samuel Antao via cfe-commits]

sfantao added a comment.

Thanks for the review!

In http://reviews.llvm.org/D11361#232045, @ABataev wrote:

> Samuel, Yes, I thought about different files and different classes. Runtime for offloading codegen is not a part of libomp and it would be good to have separate runtime handler class for target codegen also. We need to think about it in future.


Sure, we can definitely do something like that in the future if we detect a clear place to separate. I guess that when we do that, the design of the offloading-unrelated lib has to change a little. There are things like the capture statement info that may make sense to share between the two implementation.


================
Comment at: lib/CodeGen/CGOpenMPRuntime.h:188-203
@@ -179,2 +187,18 @@
   };
+
+  /// \brief Values for bit flags used to specify the mapping type for
+  /// offloading.
+  enum OpenMPOffloadMappingFlags {
+    /// \brief Allocate memory on the device and move data from host to device.
+    OMP_MAP_TO = 0x01,
+    /// \brief Allocate memory on the device and move data from device to host.
+    OMP_MAP_FROM = 0x02,
+  };
+
+  enum OpenMPOffloadingReservedDeviceIDs {
+    /// \brief Device ID if the device was not defined, runtime should get it
+    /// from environment variables in the spec.
+    OMP_DEVICEID_UNDEF = -1,
+  };
+
   CodeGenModule &CGM;
----------------
ABataev wrote:
> Move them to .cpp file.
Done!

================
Comment at: lib/CodeGen/CGOpenMPRuntime.h:761
@@ -714,2 +760,2 @@
 
 #endif
----------------
ABataev wrote:
> sfantao wrote:
> > Unlike the other enums, more than one map types need to be combined. E.g., to/from are two different enums. Once the map clause and 4.1 get to be support, we will have more combinations. I see two options here: add enums for all combinations or use a typedef each time an ineger refer to map types, so the code is more readable. Let me know your thoughts. 
> Yes, I think we need to add separate enums for different combination in Basic/OpenMPKinds.{def, h} for AST. In runtime support library we can represent these combinations as a bit-or of single mapping types.
> 
Ok, I see, it makes sense to do that from the AST for the map clause SEMA. I'm keeping the bit-or in the runtime library call codegen as you say.


http://reviews.llvm.org/D11361