This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Offloading Support in libgomp
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Ilya Verbin <iverbin at gmail dot com>
- Cc: "Michael V. Zolotukhin" <michael dot v dot zolotukhin at gmail dot com>, Kirill Yukhin <kirill dot yukhin at gmail dot com>, Richard Henderson <rth at redhat dot com>, GCC Development <gcc at gcc dot gnu dot org>, triegel at redhat dot com, sergos dot gnu at gmail dot com
- Date: Tue, 29 Oct 2013 08:03:31 +0100
- Subject: Re: [RFC] Offloading Support in libgomp
- Authentication-results: sourceware.org; auth=none
- References: <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> <20130913093417 dot GA30181 at msticlxl57 dot ims dot intel dot com> <20130916093549 dot GP1817 at tucnak dot redhat dot com> <20130917120454 dot GE60139 at msticlxl57 dot ims dot intel dot com> <20130917122927 dot GY1817 at tucnak dot redhat dot com> <20131028104110 dot GA11997 at msticlxl57 dot ims dot intel dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Oct 28, 2013 at 02:42:37PM +0400, Ilya Verbin wrote:
> We have a MIC offload runtime library (liboffload), which is an abstraction over
> COI. Currently it is a part of ICC, but there are plans of open sourcing it.
> However, liboffload requires somewhat different tables comparing to what we have
> agreed on. The liboffload tables serve to associate host functions with target
> functions. They should be inserted at compile-time into special sections of
> every executable or DSO with #pragma omp target. The tables contain pairs of:
> { char *name, void *host_addr } for host binaries, and { char *name, void
> *target_addr } for target. The "name" might be not the actual function name,
> but just a key for host->target mapping.
> So, in this approach, GOMP_target will take host_addr as input, then MIC plugin
> will convert it into the "name" by host-side table, and call on MIC using
> liboffload interface. Perhaps, additional table will be created by MIC plugin
> to speed up the name lookup. This also should eliminate problems with functions
> re-ordering at LTO where address tables from different objects will be mixed
> into one in executable/shared library.
> What do you think, is it ok to save this additional data in the tables?
See my earlier comments on why names are bad. For exported functions names
can work (though, if you use them for the whole process, things like
visibility attributes can complicate it), but for non-exported functions you
either need to fall back to names derived from first exported symbol if any,
or uuid etc., which are highly undersirable for bitwise reproduceable
builds. If liboffload requires something else, isn't it a library at a too
high level and shouldn't you use COI instead?
Jakub