This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Offloading Support in libgomp
- From: "Michael V. Zolotukhin" <michael dot v dot zolotukhin at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Kirill Yukhin <kirill dot yukhin at gmail dot com>, Richard Henderson <rth at redhat dot com>, gcc at gcc dot gnu dot org, triegel at redhat dot com
- Date: Tue, 10 Sep 2013 19:01:26 +0400
- Subject: Re: [RFC] Offloading Support in libgomp
- Authentication-results: sourceware.org; auth=none
- References: <20130823153052 dot GA2974 at msticlxl57 dot ims dot intel dot com> <20130823161631 dot GO1814 at tucnak dot redhat dot com> <20130826115911 dot GA40923 at msticlxl57 dot ims dot intel dot com> <20130826125116 dot GE21876 at tucnak dot zalov dot cz> <20130826132936 dot GB40923 at msticlxl57 dot ims dot intel dot com> <20130826141117 dot GF21876 at tucnak dot zalov dot cz> <20130827112609 dot GA4093 at msticlxl57 dot ims dot intel dot com> <20130827113956 dot GH21876 at tucnak dot zalov dot cz> <20130827115538 dot GB4093 at msticlxl57 dot ims dot intel dot com> <20130828093428 dot GO21876 at tucnak dot zalov dot cz>
Hi Jakub,
I continued playing with plugins for libgomp, and I have several questions
regarding that:
1) Would it be ok, at least for the beginning, if we'd look for plugins in a
folder, specified by some environment variable? A plugin would be considered
as suitable, if it's named "*.so" and if dlsym finds a certain set of functions
in it (e.g. "device_available", "offload_function" - names are subjected to
change of course).
2) We need to perform all libgomp initialization once at the first entry to
libgomp. Should we add corresponding checks to all GOMP_* routines or should
the compiler add calls to GOMP_init (which also needs to be introduced) by
itself before all other calls to libgomp?
3) Also, would it be ok if we store libgomp status (already initialized or not)
in some static variable? I haven't seen such examples in the existing code
base, so I don't sure it is a good way to go.
4) We'll need to store some information about available devices:
- a search tree with data about mapping
- corresponding plugin handler
- handlers for functions from the corresponding plugin
- maybe some other info
I guess that's a bad idea to store all this data in some static-sized global
variables, and it's better to dynamically allocate memory for that. But it
implies that we need to care about deallocation, which should be called at some
moment on the program end. Shouldn't we introduce something like
GOMP_deinitialize and insert calls to it during the compilation?
5) We mentioned that similar to a tree data-structure for storing info about
mapping. Am I getting it correctly, that currently there is no such
data-structure at all and we need to design and implement it from scratch?
--
Thanks, Michael