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