Fwd: [RFC][gomp4] Offloading patches (2/3): Add tables generation

Bernd Schmidt bernds@codesourcery.com
Thu Mar 6 11:54:00 GMT 2014


On 03/06/2014 12:11 PM, Ilya Verbin wrote:

> Do I understand correctly, that you propose to do so:
>
> extern void *_omp_host_func_table[];
> extern void *_omp_host_var_table[];
> extern void *_omp_host_funcs_end[];
> extern void *_omp_host_vars_end[];
>
> void *__OPENMP_TARGET_HOST__[]
> __attribute__ ((visibility ("protected"))) =
> {
>    &_omp_host_func_table, &_omp_host_funcs_end,
>    &_omp_host_var_table, &_omp_host_vars_end
> };

So far, yes (maybe just call it __OPENMP_HOST_TABLE__).

> extern void *__OPENMP_TARGET_MIC__[];
> extern void *__OPENMP_TARGET_PTX__[];
> extern void GOMP_offload_register_host (const void *);
> extern void GOMP_offload_register_target (const void *);
>
> __attribute__ ((constructor))
> static void
> init (void)
> {
>    GOMP_offload_register_host (__OPENMP_TARGET_HOST__);
>    GOMP_offload_register_target (__OPENMP_TARGET_MIC__);
>    GOMP_offload_register_target (__OPENMP_TARGET_PTX__);
> }
>
> Where __OPENMP_TARGET_MIC__ and __OPENMP_TARGET_PTX__ descriptors
> should be generated in the corresponding mkoffload tools.

No. I don't think we need a global constructor for registering 
__OPENMP_TARGET_HOST__ - this would unnecessarily bloat crtbegin/crtend. 
  We also shouldn't need to have the target tables known outside of the 
image constructed by the mkoffload tools.  The way I imagine it, every 
mkoffload tool creates its own constructor that looks like something 
like this:

__attribute__ ((constructor)) static void
init (void)
{
    GOMP_offload_register_target (__OPENMP_TARGET_HOST__,
                                  PTX_ID, ptx_target_table);
}

That creates a mapping between host and target table for PTX_ID. If 
there are multiple shared libraries with offload support, you can still 
obtain the ordering you want from these GOMP_offload_register_target 
calls. Everything is nicely private to the mkoffload-generated image.

It's implemented in almost this fashion (slightly different naming and 
args, and no real support in libgomp) in the patch kit I sent.


Bernd



More information about the Gcc-patches mailing list