This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]