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