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

Ilya Verbin iverbin@gmail.com
Wed Mar 5 17:15:00 GMT 2014


On 28 Feb 17:21, Bernd Schmidt wrote:
> I think it won't help that much - I still think this entire scheme
> is likely to fail on nvptx. I'll try to construct an example at some
> point.
> 
> One other thing about the split tables is that we don't have to
> write a useless size of 1 for functions.
> 
> 
> The concept of "image" is likely to vary somewhat between
> accelerators. For ptx, it's just a string and it can't really be
> generated the same way as for your target where you can manipulate
> ELF images. So I think it is better to have a call to a gomp
> registration function for every offload target. That should also
> give you the ordering you said you wanted between shared libraries.
> 
> 
> Probably. I think the constructor call to the gomp registration
> function would contain an opaque pointer to whatever data the target
> wants, so it can arrange its image/table data in whatever way it
> likes.

Assuming that we're using the scheme with tables.
Every DSO with offloading must contain a constructor call to GOMP_offload_register (const void *openmp_target);
The openmp_target descriptor in every DSO will have target-independent entries (addresses of host tables) and target-dependent entries for each target. Its format may be like this:

void *__OPENMP_TARGET__[] =
{
  _omp_host_func_table;
  _omp_host_funcs_end;
  _omp_host_var_table;
  _omp_host_vars_end;
  _omp_num_targets;
  _omp_target_descs[]; /* array of tgt_desc */
}

struct tgt_desc
{
  int _omp_tgt_id;
  void *_omp_tgt_%s_image_start;
  void *_omp_tgt_%s_image_end;
  void *_omp_tgt_%s_func_mappings;
  void *_omp_tgt_%s_var_mappings;
  /* some other data if needed */
}

The mkoffload tool will fill those symbols, that are required by the corresponding target.
E.g. for the MIC and PTX targets the openmp_target descriptor will look like:

{
  &_omp_host_func_table,
  &_omp_host_funcs_end,
  &_omp_host_var_table,
  &_omp_host_vars_end,
  2,

  MIC_ID,
  &_omp_tgt_mic_image_start,
  &_omp_tgt_mic_image_end,
  &_omp_tgt_mic_func_mappings, /* 0 */
  &_omp_tgt_mic_var_mappings, /* 0 */

  PTX_ID,
  &_omp_tgt_ptx_image_start,
  &_omp_tgt_ptx_image_end, /* 0 */
  &_omp_tgt_ptx_func_mappings,
  &_omp_tgt_ptx_var_mappings
}

During the devices initialization libgomp will pass the openmp_target pointer to all plugins. Each plugin will scan over tgt_descs and find the required entries using the _omp_tgt_id.
Then the plugin loads the image to the target, does whatever it wants, and returns func_mappings and var_mappings to libgomp, because libgomp has to add host-target mapping into the splay tree.
How does this look?

BTW, do you have any estimate when you will commit your patches to the branch, so that we could merge them with ours, and get something working for everybody?

  -- Ilya



More information about the Gcc-patches mailing list