Ping.
On 20 December 2013 20:46, Michael V. Zolotukhin <michael.v.zolotuk...@gmail.com> wrote: >> This patch seems to make rather too many assumptions about host and >> target compilers. Certainly code like this can't go into >> target-independent code like lto-wrapper. > That's true. The point of this patch was to show what is needed to support > x86->MIC OpenMP offloading, as we currently see it. We are ready to extend > existing code making it more versatile, but keeping this needed functionality. > >> Also, I'm not sure you can >> assume you'll get ELF files out of the OpenACC target compiler; I'd very >> prefer a solution that doesn't rely on objcopy. > Yep, that's an issue I suspected but wasn't sure of. > > The idea was to prepare an image in the following steps: > 1. Compile with target compiler. > 2. Post-process it (in our case, call objcopy and perform partial linking). > 3. Pass it to the host linker as a usual object file with the image and its > size placed in the known symbols with defined names (e.g. > _omp_<target-name>_image). > > I would like to keep step 3 unchanged, while the steps 1 and 2 could be easily > combined into a single one. > > In that case we could say that output of a target compiler should be an object > file for host linker with several symbols defined: _omp_<target-name>_image, > _omp_<target-name>_size, etc. > > For x86->MIC one would use gcc+objcopy for this, and for OpenACC offloading > one > could use gcc+some of other target-specific utils (if any of them needed). > > Will this scheme work for OpenACC? > > Michael >> Bernd
