On Mon, Sep 28, 2015 at 11:39:10AM +0200, Thomas Schwinge wrote:
> Hi!
>
> On Fri, 11 Sep 2015 17:43:49 +0200, Jakub Jelinek <ja...@redhat.com> wrote:
> > So, do I understand well that you'll call GOMP_set_offload_targets from
> > construct[ors] of all shared libraries (and the binary) that contain
> > offloaded
> > code? If yes, that is surely going to fail the assertions in there.
>
> Indeed. My original plan has been to generate/invoke this constructor
> only for/from the final executable and not for any shared libraries, but
> it seems I didn't implemented this correctly.
How would you mean to implement it? -fopenmp or -fopenacc code with
offloading bits might not be in the final executable at all, nor in shared
libraries it is linked against; such libraries could be only dlopened,
consider say python plugin. And this is not just made up, perhaps not with
offloading yet, but people regularly use OpenMP code in plugins and then we
get complains that fork child of the main program is not allowed to do
anything but async-signal-safe functions.
>
> > You can dlopen such libraries etc. What if you link one library with
> > -fopenmp=nvptx-none and another one with -fopenmp=x86_64-intelmicemul-linux?
>
> So, the first question to answer is: what do we expect to happen in this
> case, or similarly, if the executable and any shared libraries are
> compiled with different/incompatible -foffload options?
As the device numbers are per-process, the only possibility I see is that
all the physically available devices are always available, and just if you
try to offload from some code to a device that doesn't support it, you get
host fallback. Because, one shared library could carefully use device(xyz)
to offload to say XeonPhi it is compiled for and supports, and another
library device(abc) to offload to PTX it is compiled for and supports.
> For this, I propose that the only mode of operation that we currently can
> support is that all of the executable and any shared libraries agree on
> the offload targets specified by -foffload, and I thus propose the
> following patch on top of what Joseph has posted before (passes the
> testsuite, but not yet tested otherwise):
See above, no.
Jakub
