On Tue, Sep 03, 2013 at 05:59:35PM +0400, Michael V. Zolotukhin wrote:
> Let's continue this discussion.
>
> Summing up what was said above, I think we need following changes in
> LTO-infrastructure to enable offloading:
> * [in lto_plugin] claim files with .openmp (or whatever
> name) sections along with files containing .lto sections, as we do now
I'd go with .gnu.target_lto* names (i.e. s/.gnu.lto/.gnu.target_lto/
on the existing LTO section names if they are for the accelerator rather
than host).
> * [in lto_plugin] check if resolution file is generated
> correctly and probably fix it a bit to properly handle LTO and OpenMP
> handling (separately from each other)
> * [in WPA] save .openmp sections to a new partition (in future - into
> several new partitions).
> * [in WPA] save a copy of symtab (or its subset) to this
> openmp-partition.
> * [in lto_wrapper] compile the openmp-partition with gcc-target and
> then link it with ld-target
I really have almost zero experience with LTO, but I don't see how you could
use any resolution for those sections. The resolution handling in the
linker will be for the host link, you want something along the lines of:
- if you find .gnu.target_lto* sections, feed those (one CU at a time) to
the target compiler driver with some magic option that it will use lto1
backend and will read from the .gnu.target_lto* sections instead of
.gnu.lto*; and, at least when not -flto, you want it to just generate
assembly for the target, and let the target driver also invoke assembler
- collect all those target object files from the link, link them together
using target compiler driver, and feed back the resulting binary
or shared library into the host linking (some magic section in there)
But, the target support has to work even without -flto, and for
debuggability etc. reasons I wouldn't force compiling all the target code
together unless required by the target.
Jakub
