Questions about LTO infrastructure and pragma omp target

[Michael V. Zolotukhin]

> > Oh, if we just link the target binary as a data section into the host
> > binary, then I see no problems in that, it seems absolutely feasible
> > with the existing infrastructure.  I just thought (seemingly it was
> > incorrect) that we're speaking about linking of target code with the
> > host code.
> 
> No.  The rough idea is that you emit the accelerator related subset of CUs
> into the (special named) LTO sections, and when linking a binary you collect
> all those sections from all the input object files, compile those (without
> -flto ideally separately), link together and finally embed into the
> executable into a data section.  Similarly when linking a shared library,
> you do a target shared library and embed it in a data section of the host
> shared library.  It is kind of fat binaries/shared libraries.  Each of the
> accelerators would use different name of the data sections, so they could
> coexist.
Thanks, that matches with my understanding.

> For the MIC, you'd then use COI to create the binary or shared libraries
> from the (ro)data section memory image.  For others whatever they support.
> Perhaps it should be for MIC a shared library even in the binary and have
> some binary in a data section of the libgomp plugin, because it really
> should work also if the host binary doesn't have any #pragma omp target
> in it at all, but shared libraries do.
I haven't thought about possible issues with shared libraries using offload yet,
but they surely deserve careful consideration.

Michael
> 	Jakub