2014-02-20 22:27 GMT+04:00 Bernd Schmidt <ber...@codesourcery.com>:
>  * Functions and variables now go into different tables, otherwise
>    intermixing between them could be a problem that causes tables to
>    go out of sync between host and target (imagine one big table being
>    generated by ptx lto1/mkoffload, and multiple small table fragments
>    being linked together on the host side).

If you need 2 different tables for funcs and vars, we can also use
them. But I still don't understand how it will help synchronization
between host and target tables.

>  * I've put the begin/end fragments for the host tables into crtstuff,
>    which seems like the standard way of doing things.

Our plan was that the host side descriptor __OPENMP_TARGET__ will
contain (in addition to func/var table) pointers to the images for all
enabled accelerators (e.g. omp_image_nvptx_start and
omp_image_intelmic_start), therefore we generated it in the
lto-wrapper. But if the number of accelerators and their types/names
will be defined during configuration, then it's ok to generate the
descriptor in crtstuff.

>  * Is there a reason to call a register function for the host tables?
>    The way I've set it up, we register a target function/variable table
>    while also passing a pointer to the __OPENMP_TARGET__ symbol which
>    holds information about the host side tables.

In our case we can't register target table with a call to libgomp, it
can be obtained only from the accelerator. Therefore we propose a
target-independent approach: during device initialization libgomp
calls 2 functions from the plugin (or this can be implemented by a
single function):
1. devicep->device_load_image_func, which will load target image (its
pointer will be taken from the host descriptor);
2. devicep->device_get_table_func, which in our case connects to the
device and receives its table. And in your case it will return
func_mappings and var_mappings. Will it work for you?

>  * An offload compiler is built with --enable-as-accelerator-for=, which
>    eliminates the need for -fopenmp-target, and changes install paths so
>    that the host compiler knows where to find it. No need for
>    OFFLOAD_TARGET_COMPILERS anymore.

Unfortunately I don't fully understand this configure magic... When a
user specifies 2 or 3 accelerators during configuration with
--enable-accelerators, will several different accel-gccs be built?

Thanks,
  -- Ilya

Reply via email to