On 02/14/2014 04:12 PM, Jakub Jelinek wrote:
On Fri, Feb 14, 2014 at 04:01:46PM +0100, Bernd Schmidt wrote:
What I'm currently trying to do is to use get_file_function_name,
which should provide a unique string that can be used to look up an
offloaded function. That was suggested by Nathan Sidwell, I'd
forgotten that such a function existed. I haven't actually given
thought to whether that'll be unique across multiple DSOs, but as
long as we also pass a value to the libgomp registration function
that is unique per DSO, that shouldn't really matter - we should be
able to reliably look up a function given these two keys.
get_file_function_name is very problematic, it is not unique across DSOs,
and relies on -frandom-seed which user can tweak and even without tweaking
can have collisions in, if we can avoid it at all, we should.
Not to mention that strings, especially get_file_function_name based ones,
aren't really short and will occupy much more space than the tables.
How many offloaded functions do we really expect to have in an
executable? I don't think that's likely to be a bottleneck.
The use of a random-seed is really just a fallback, preferrably it uses
the name of first symbol defined in the current translation unit which I
think ought to be reliable enough.
I still don't see what you find wrong on the approach with host/target
address arrays, if you are afraid something will reorder the arrays
(but, what would do that), one can insert indexes into both arrays as well,
which the linker can fill in and you can then verify.
It strikes me as really unnecessarily brittle. On the host side we'd
have multiple objects linked together in some order to produce such a
table, on the ptx side we'd have to produce the table all in one go.
Factor in possibilities like function cloning and I just think there are
too many ways in which this can utterly fail. I'd rather have something
that is more robust from the start even if it's slightly less efficient.
Bernd
