This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Fwd: [RFC][gomp4] Offloading patches (2/3): Add tables generation
- From: Ilya Verbin <iverbin at gmail dot com>
- To: Bernd Schmidt <bernds at codesourcery dot com>
- Cc: "Michael V. Zolotukhin" <michael dot v dot zolotukhin at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>, Thomas Schwinge <thomas at codesourcery dot com>, Richard Biener <rguenther at suse dot de>, Kirill Yukhin <kirill dot yukhin at gmail dot com>, Andrey Turetskiy <andrey dot turetskiy at gmail dot com>, Ilya Tocar <tocarip dot intel at gmail dot com>, gcc <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 28 Jan 2014 16:52:57 +0400
- Subject: Fwd: [RFC][gomp4] Offloading patches (2/3): Add tables generation
- Authentication-results: sourceware.org; auth=none
- References: <20131217113957 dot GA39975 at msticlxl57 dot ims dot intel dot com> <52E7927B dot 8030509 at codesourcery dot com> <CADG=Z0GQ8ORLe1XRUU7VMYeLhwuWisMyCcGLQj-nY_bhkbD_1Q at mail dot gmail dot com>
Adding gcc-patches.
Hi Bernd,
The table is used in libgomp (see my patch [1]), as proposed by Jakub
(see [2]). The idea is that the order of entries in the host and
target tables must be identical. This allows to set up one-to-one
correspondence between host and target addresses.
In my patch libgomp calls device_init_func from the plugin, that loads
all libraries to the target, and returns the joint table with
addresses for all libraries. But probably it's better to have a
function like device_load, that will load only one library image, an
return a table for this library.
[1] http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01896.html
[2] http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01392.html
-- Ilya
2014/1/28 Bernd Schmidt <bernds@codesourcery.com>
>
> On 12/17/2013 12:39 PM, Michael V. Zolotukhin wrote:
>>
>> Here is a patch 2/3: Add tables generation.
>>
>> This patch is just a slightly modified patch sent a couple of weeks ago. When
>> compiling with '-fopenmp' compiler generates a special symbol, containing
>> addresses and sizes of globals/omp_fn-functions, and places it into a special
>> section. Later, at linking, these sections are merged together and we get a
>> single table with all addresses/sizes for entire binary. Also, in this patch we
>> start to pass '__OPENMP_TARGET__' symbol to GOMP_target calls.
>
>
> I also have a question about the code in this patch. I can see how the table is constructed - what's not clear to me is how it is going to be used? How do you map from a function or variable you want to look up to an index in this table?
>
>
> Bernd
>