> > 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
