Re: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC

[Tobias Burnus]

On 6/23/20 9:36 PM, Thomas Schwinge wrote:

>> (*) Thomas mentioned that this is supposed to work also in more
>> complex cases than the one I outlined, although, that is probably
>> currently the most common one.
> Static linking is another such case that we've seen in the wild

What I meant was: single library (static or dynamic) contains all
offloading code – and rest of the code is free of offloading code.
I think those two are the second most common – while a code where
all offloading bits are in the program and not the library is by
far the #1. – Other variants are much less likely, but who knows
what users are doing...

> I don't think I can approve, but seems fine if this works (as you've
> confirmed) -- it's one incremental step forward!
>
> Or, should this instead be handled in the LTO wrapper (?) options merging
> etc. machinery?  I'd have to dig in further.  (Jakub?)

The produced code cannot be much optimized (some tables), hence,
some fancy flags are not needed (contrary to LTO). However, there
might be other ABI relevant options besides -fPIC/-fpic (some
-m... flag? For GCN, -march= is crucial, some ARM platform might
have the same issue?)

> What about 'gcc/config/i386/intelmic-mkoffload.c'?  I see that one
> unconditionally passes '-fPIC' to some things -- is that doing the right
> thing for your case, too?

I have not setup intelmic to test, but it uses -fPIC -share throughout
and in particular for the sister function to the one to those patched.
Hence, I expect that it will simply work. – But I wouldn't mind if you
could test that it indeed does work.

Cheers,

Tobias

-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter