[Parallel_libs-commits] [PATCH] D24195: [SE] GlobalDeviceMemory owns its handle

Jason Henline via Parallel_libs-commits parallel_libs-commits at lists.llvm.org
Fri Sep 2 10:20:07 PDT 2016


jhen added inline comments.

================
Comment at: streamexecutor/include/streamexecutor/DeviceMemory.h:126
@@ +125,3 @@
+/// create new GlobalDeviceMemoryBase objects, and comparing them to each other
+/// for equality.
+class GlobalDeviceMemoryBase {
----------------
jlebar wrote:
> Is this last paragraph still fully correct?
No, it was not. I just removed it completely because I think it's not needed anyway.

================
Comment at: streamexecutor/include/streamexecutor/DeviceMemory.h:136
@@ +135,3 @@
+  explicit GlobalDeviceMemoryBase(Device *D, const void *Handle = nullptr,
+                                  size_t ByteCount = 0)
+      : TheDevice(D), Handle(Handle), ByteCount(ByteCount) {}
----------------
jlebar wrote:
> Do the handle and byte count still need to be optional?  I guess you can change it later.
I changed it now. They don't need to be optional.

================
Comment at: streamexecutor/include/streamexecutor/DeviceMemory.h:167
@@ +166,3 @@
+  GlobalDeviceMemoryBase(const GlobalDeviceMemoryBase &) = delete;
+  GlobalDeviceMemoryBase &operator=(const GlobalDeviceMemoryBase &) = delete;
+};
----------------
jlebar wrote:
> These don't need to be private if you don't want.
I'm never sure where is the best place to put these because the visibility doesn't seem to matter. I moved them into the public section to prevent creating a new section for them. Does that seem cleaner?

================
Comment at: streamexecutor/include/streamexecutor/DeviceMemory.h:235
@@ -234,3 +219,1 @@
 /// launch the kernel.
-class SharedDeviceMemoryBase {
-public:
----------------
jlebar wrote:
> Why are we getting rid of SharedDeviceMemoryBase?
> 
> I don't have a strong opinion one way or another, but it's not clear to me why this is an improvement.
> 
> The main advantage of SharedDeviceMemoryBase, I guess, is that you can accept one as a const ref parameter to a function without a template.
I think its an improvement because we ain't gonna need it. If it becomes useful later on, we can add it back in, but it doesn't seem like it will.


https://reviews.llvm.org/D24195





More information about the Parallel_libs-commits mailing list