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
