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



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to