[Openmp-dev] [RFC] Device runtime library (re)design

[Doerfert, Johannes via Openmp-dev]

On 08/08, Joel E. Denny wrote:
> Hi Johannes,
> 
> Thanks for working on this.  A brief question inline....
> 
> > Sources
> > -------
> > For the device RTL it currently looks like this:
> >   openmp/libomptarget/deviceRTLs/nvptx/{docs,src,test,CMakeLists.txt}
> > The test structure is discussed later. docs is pretty much empty and it
> > should probably live with the common logic. src is discussed now:
> >
> > I now assume we will have a common core (probably header only), and
> > device specific code that may or may not use common core parts. The
> > structure I imagine looks like this:
> >   openmp/libomptarget/deviceRTLs/common/include/{queue.h,
> > target_impl.h,...}
> >   openmp/libomptarget/deviceRTLs/nvptx/{libomptarget.cu
> > ,CMakeLists.txt,...,include/target_impl.h,...}
> >
> > openmp/libomptarget/deviceRTLs/amdgpu/{libomptarget.hip,CMakeLists.txt,...,include/target_impl.h,...}
> >
> > openmp/libomptarget/deviceRTLs/CPU/{libomptarget.XYZ,CMakeLists.txt,...,include/target_impl.h,...}
> >
> > openmp/libomptarget/deviceRTLs/.../{libomptarget.XYZ,CMakeLists.txt,...,include/target_impl.h,...}
> > I added a CPU version above to ease testing (see below) and to provide a
> > target_impl.h declaration for better IDE support.
> >
> > - The common files could be header only (debatable and not strictly
> > necessary).
> > - All source files that need to be compiled and linked into a library
> >   for this device (as IR or object files) are listed in the device
> >   CMakeLists.txt file. This can include common source files if the
> >   common files are not header only. There is no need to include any
> >   common files if the device implementation is self-contained.
> > - To make target definitions available to common files we would:
> >
> 
> Why do target definitions need to be made available to common files?  Is it
> only for the case that common has source not just headers, and that source
> must be compiled per device?

Good question. Yes, and especially when the common source (that is
compiled alone) contains references to template functions/classes which
we can only declare in the common code but need to define in the target
code. The atomic add example below was my motivation. We want a generic
atomic add for various types so templates seemed like a good option but
the definition is target specific. As we discussed before, we might not
want to use templates after all but specify the versions we would
generate explicitly. We then wouldn't need to make the definitions
available. Neither would we need that for uses in the "header only"
part of the common code.

Does that make sense?


> >     * put target specific function declarations, e.g.,
> >        `template <typename T> T __kmpc_impl_atomic_add(T *Ptr, T Val)`
> >       in common/include/target_impl.h.
> >     * put implementations in {nvptx,amdgpu,...}/include/target_impl.h.
> >     * have a `#include_next "target_impl.h"` in
> > common/include/target_impl.h.
> >     * have the common/include and one device include folder in the
> >       include path (in this order) when we compile any file.
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20190808/a1cc69db/attachment-0001.sig>