On Wed, Sep 18, 2013 at 06:13:25PM +0400, Michael V. Zolotukhin wrote:
> > As discussed earlier, I'd like to pass __OPENMP_TARGET__ argument to
> > all of GOMP_target{,_data,_update}, so that all those functions
> > can get at the offloading data section in the shared library or binary
> > making the call, so that the first time they encounter such a call
> > in the shared library or binary, it can attempt to actually offload
> > it to the target (and, if that fails, remember it, and do host fallback).
> Actually, I thought that that we'd perform loading the target code in
> gomp-initialization. So, first time libgomp is called, it loads target image
> (from somewhere) and starts the target-side MAIN on the target (which actually
> just starts to wait for offload requests). Then, when GOMP_target is called,
> it
> just passes address (or name, as it was initially) to this target-side MAIN
> and
> the target executes the requested function. I thought that at the moment
> GOMP_target is called everything is ready and loaded as initialization has
> been
> already executed. Isn't that correct? Maybe I misunderstood something - do
> you
> want to load target images only in GOMP_target, not earlier?
Yes, I want to load target images only in GOMP_target{,_data,_update}.
Loading it earlier is both premature (if you have say two MICs, one HSAIL
available, why would you upload everything to all 3 devices, even when you
don't know if the program will just print usage and exit and never enter any
target region), and hard to do (a program can have many shared libraries
(plus the binary), and each of them can have their offload stuff, how do you
find out what to offload and what not, and from where?).
__OPENMP_TARGET__ would be a linker plugin inserted symbol at the start of
some linker plugin created data section, which would start with some header
and then data.
Say
uleb128 number_of_supported_targets - n
uleb128 number_of_host_var_pairs - m
[ name of offload target (asciiz?)
relative offset to the start of the offload data for the target (in MIC case
embedded DSO)
size of the offload data
perhaps something how to find the target addresses array
] repeated n times
[ host_address, size ] repeated m times
(for the functions passed to GOMP_target the pair would be [ foobar.omp_fn.25,
1 ] ).
If no offload data is provided at all, then the section would be just one
byte - 0 (or two bytes, 0 0)?
So, when GOMP_target{,_data,_update} is called, it could easily determine
if the calling shared library resp. binary has been offloaded or not (it
could e.g. have a few entries array as cache, otherwise lookup the
__OPENMP_TARGET__ address in the splay tree or something?
If it sees it hasn't been initialized yet, if it is the very first time,
for MIC it would upload the binary (from the plugin data section?), libgomp
and finally the shared library from the __OPENMP_TARGET__ and initialize the
splay tree with the variables.
> And I still not quite get it, how would target code know, which function to
> call
> in this scheme. How will it figure out, which function to call if we didn't
> even pass the function name? As far as I understand, __OPENMP_TARGET__ will
See earlier mail, function names aren't neccessarily unique. After the
__OPENMP_TARGET__ shared library is dlopened in the target and splay tree
initialized from the host array of [host_address, size] pairs and
corresponding array of target_address in the target code, you just lookup
the [ fnaddr, 1 ] in the splay tree and use the target address from that
mapping.
> lead to a dedicated section, which contains addresses of host-side versions of
> the functions. But how could we obtain the corresponding addresses for the
> target? COI, e.g., as I understand it, currently doesn't have a capability of
> returning target-side function address - it only could call a function by
> name.
> Or am I missing something?
Jakub
