[Openmp-dev] CMake overhaul

[Sergey Ostanevich]

Chandler, Chris,

Could you have a look at my proposal for OpenMP offloading at
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-April/042640.html

There's only one picture that explains the position of liboffload very
well: a box named "Phi offload RTL" is exactly the liboffload we're
discussing. In this proposal the OpenMP-specific bookkeeping of
offloaded data, code and pointers is done inside libomptarget.so, so
the liboffload is abstract from this point of view. Historical
background: originally liboffload was a proprietary interface of Intel
compiler (and it remains to be).

I see the following points here:
- liboffload is naturally not a part of OpenMP infrastructure, rather
lower level interface for the offloading
- liboffload that is discussed supports Intel MIC platform only and
can't be easily reused for other targets
- testing of the liboffload can be done using LIT tests, although
easiest way to obtain them is through the OpenMP sources
- I am not sure if proposed offload RTL interface suits all mentioned
programming model and asking for your help here - we can update the
interface to be as versatile as possible

So contrary to Chandler's proposal I believe there should be something like

.../offload/intelmic/src/...
.../offload/intelmic/test/...
.../offload/nvidia/src/...
.../offload/nvidia/test/...

As for the cross-platform part - the libomptarget.so - it has
OpenMP-specific interface provided to compiler and relies on
underlying interface that is defined by the liboffload. So this part
naturally should go somewhere in libomp repo as part of OpenMP 4.0
support with tests placed along with other at
.../tools/clang/test/OpenMP/...


Regards,
Sergos


On Tue, Jun 23, 2015 at 11:06 AM, Chandler Carruth <chandlerc at google.com> wrote:
> On Tue, Jun 23, 2015 at 12:50 AM C Bergström <cbergstrom at pathscale.com>
> wrote:
>>
>> In regards to Chandlers questions
>>
>> liboffload absolute does not belong inside libomp. Any reference to it
>> is likely Intel legacy. They should work together, but liboffload is
>> something which IMHO should be used by other programming models and
>> not tightly coupled only to OMP.
>>
>> (OpenCL, C++AMP, CUDA. etc)
>
>
> I'd like to see generic offloading and device runtime libraries in LLVM as
> well, but a) they don't belong in the 'openmp' project, and b) this doesn't
> seem to be it (at least in its current form).
>
> This really looks like a specific implementation of the OpenMP 4.0
> offloading runtime support. the 'offload.h' header defines a wide range of
> OpenMP APIs for offloading and only reserved names for a a very small number
> of generic offloading interfaces.
>
> There is probably some really good generic offloading logic *inside* this
> that would be good to extract into a common accelerator / offloading runtime
> library though. But probably into a separate runtime project from this one,
> and there would still probably be an openmp offloading runtime library to
> satisfy the 4.0 spec stuff.
>
> Maybe I've misunderstood the contents of the library?
> -Chandler
>
>>
>> _______________________________________________
>> Openmp-dev mailing list
>> Openmp-dev at dcs-maillist2.engr.illinois.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev
>
>
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at dcs-maillist2.engr.illinois.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev
>