This is an archive of the discontinued LLVM Phabricator instance.

[SE] GlobalDeviceMemory owns its handle
ClosedPublic

Authored by jhen on Sep 2 2016, 9:42 AM.

Details

Summary

Final step in getting GlobalDeviceMemory to own its handle.

  • Make GlobalDeviceMemory movable, but no longer copyable.
  • Make Device::freeDeviceMemory function private and make GlobalDeviceMemoryBase a friend of Device so GlobalDeviceMemoryBase can free its memory in its destructor.
  • Make GlobalDeviceMemory constructor private and make Device a friend so it can construct GlobalDeviceMemory.
  • Remove SharedDeviceMemoryBase class because it is never used.
  • Remove explicit memory freeing from example code.

This change just consumes any errors generated during device memory freeing.
The real error handling will be added in a future patch.

Diff Detail

Event Timeline

jhen updated this revision to Diff 70177.Sep 2 2016, 9:42 AM
jhen retitled this revision from to [SE] GlobalDeviceMemory owns its handle.
jhen updated this object.
jhen added a reviewer: jlebar.
jhen added subscribers: parallel_libs-commits, jprice.
jlebar added inline comments.Sep 2 2016, 9:58 AM
streamexecutor/include/streamexecutor/DeviceMemory.h
126

Is this last paragraph still fully correct?

136

Do the handle and byte count still need to be optional? I guess you can change it later.

167

These don't need to be private if you don't want.

235

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.

jhen updated this revision to Diff 70184.Sep 2 2016, 10:19 AM
jhen marked 2 inline comments as done.
  • Respond to jlebar's comments
streamexecutor/include/streamexecutor/DeviceMemory.h
126

No, it was not. I just removed it completely because I think it's not needed anyway.

136

I changed it now. They don't need to be optional.

167

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?

235

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.

jlebar accepted this revision.Sep 2 2016, 10:22 AM
jlebar edited edge metadata.
jlebar added inline comments.
streamexecutor/include/streamexecutor/DeviceMemory.h
174

Right, I don't think visibility matters because visibility doesn't factor into C++ overloading rules.

I think it's sort of cleaner to put them up top like you did here because the fact that it's not copyable is in reality part of the "public interface".

This revision is now accepted and ready to land.Sep 2 2016, 10:22 AM

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.

That sounds great to me. :)

This revision was automatically updated to reflect the committed changes.