[PATCH] D21482: Support/ELF: Add R_AMDGPU_GOTPCREL relocation

Tom Stellard via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 20 09:24:18 PDT 2016


tstellarAMD added a comment.

In http://reviews.llvm.org/D21482#462100, @rafael wrote:

> > We only support generating shared libraries of GPU code.  The shared libraries are loaded into memory, and then the CPU host code is essentially calling functions in the GPU libraries (not directly calling them directly, but using a GPU runtime library, like OpenCL, for example, to invoke the functions).
>
> > 
>
> > We don't support preemption, but we need to use a got for referencing external variables.
>
>
> Sorry, I am still missing something.
>
> By "external", you mean "not in the .o" or "not in the .so". You don't
>  need a got to access things that are in the .so if you don't support
>  preemption. If they are external to the .so, where are they? Is it
>  possible to structure a gpu program as multiple .so files?


"external" means not in the .so.  There can be multiple .so files.  A common case for this is on a multiple GPU system where you have one .so  for data that is stored in device memory.  This device .so is loaded into the device memory of each GPU (so one copy of the .so per device).  Then you have a second .so for data that is stored in host memory.  There is only a single copy of this .so which is stored in host memory that can be accessed by all devices.  The .so stored in device memory will access variables defined in the .so stored in host memory.

One question I have is if we don't support pre-emption, is there some way for the whole tool chain to know this, so the linker is able to resolve more symbols at link time?


http://reviews.llvm.org/D21482





More information about the llvm-commits mailing list