Hi!

On Tue, 14 Jul 2015 19:59:17 -0400, Nathan Sidwell <nat...@acm.org> wrote:
> This patch turned out a little larger than expected as I ran into an API 
> limitation between libgomp and the plugins.
> 
> The patch changes GOMP_offload_{,un}register to take a pointer to constant 
> target data.  I've fixed up the two mkoffloads to constify their target data.


> The other thing this does is change the interface between libgommp and the 
> plugin's load_image and unload_image routines.  I've added the ability to 
> return 
> a pointer to target-specific connection data, and have it provided to the 
> unload 
> function.  The ptx routines allocate some storage during loading, but had no 
> way 
> to free it on onloading. (Actually, the unloading was rather broken, 
> attempting 
> to free the wrong thing.)  this data is stashed in the map created for 
> host->target fns & vars.

Julian once came up with a patch to »Fix OpenACC shutdown and PTX image
unloading (PR65904)«,
<http://news.gmane.org/find-root.php?message_id=%3C20150501104719.1355dd4c%40octopus%3E>,
but apparently that never got committed?  (Waiting for approval
by Jakub, I guess?)


> There doesn't appear to be an intelmic plugin to modify.

It lives in liboffloadmic/plugin/.


> I expect the next patch in this series to break the API between mkoffload and 
> libgomp -- adding version numbering.

»Adding version numbering« means to use regular symbol versioning in
libgomp for the GOMP_offload_register function?

> I could do this just for PTX (and have an 
> inferior long term solution), or modify intelmic too.  Preference?

So far, the preference has been to keep things (in this case: the
intelmic and nvptx plugins; or OpenMP and OpenACC offloading) as similar
as possible, striving for converging them into one unified API.  So, it
makes sense to modify intelmic, too.  (But of course, we have not yet
seen ;-) your suggested changes.)


Grüße,
 Thomas

Attachment: signature.asc
Description: PGP signature

Reply via email to