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

[Jeff Hammond via Openmp-dev]

You are proposing to use C++ in the OpenMP RTL? That will make it dependent on the C++ compiler runtime, no?

Jeff

> On Jul 5, 2019, at 1:46 PM, Doerfert, Johannes via Openmp-dev <openmp-dev at lists.llvm.org> wrote:
> 
> This proposal does not try to have a pure c++ device runtime library. I want a core implemented in C++, or just interpretable as C++, and device specific parts implemented in a different clang supported language.
> 
> When I tried to do the OpenMP rewrite a while ago I also realized we need 5.0 or even 5.1 features to do so. Once we do, there will still be device specific parts that require other languages or language extensions, e.g. intrinsics. However, clang already supports cuda intrinsics in offloaded regions when we are targeting nvptx.
> 
> 
> Get Outlook for Android
> 
> From: Alexey Bataev <Alexey.Bataev at ibm.com>
> Sent: Friday, July 5, 2019 2:32:55 PM
> To: Doerfert, Johannes
> Cc: openmp-dev at lists.llvm.org; Gregory.Rodgers at amd.com; Xinmin Tian; Rokos, Georgios; Finkel, Hal J.; Hernandez, Oscar R.; Lingda Li; Denny, Joel
> Subject: Re: [RFC] Device runtime library (re)design
>  
> Some time ago we had an idea to rewrite the device part of the library using C++ with OpenMP declare target constructs. I think, it would be good to try to write the lib using OpenMP. But, most probably, we're missing some important parts, like device only declare target and,most probably, declare variant for some device specific constructs.
> But you can start to work on this or try to implement declare target device only part. 
> I don't think that pure C++ will work here since those libraries are purely device libraries. And you need some constructs to express this important part. Not sure that pure C++ will allow to do this.
> 
> Best regards,
> Alexey Bataev
> 
> > 5 июля 2019 г., в 13:16, Doerfert, Johannes <jdoerfert at anl.gov> написал(а):
> > 
> > Tl;dr
> > We should extract device specific code out of the OpenMP deviceRTL such that we can reuse the common logic (>90%) for all devices.
> > We also need to improve the documentation and we should think about bringing the code into the LLVM coding style.
> > 
> > 
> > Requested changes:
> > I would like is to change the OpenMP device runtime library design (openmp/libomptarget/deviceRTLs) towards the following goals:
> > 1) Allow reuse of common logic between different devices in a clean and extensible way.
> > 2) Improve the documentation, e.g., doxygen comments and code comments, for the code.
> > 3) Follow the same coding style as LLVM core.
> > 
> > Disclaimer:
> > First, I do not want to say it currently is impossible the reuse the code for other devices or the code is not documented at all. What I
> > think is that we can improve both substantially if we choose to do so. Also, a change in coding style is easier now than later, so if we
> > decide to do refactoring, that can be included without adding to much churn.
> > 
> > Motivation:
> > Now we can discuss if we should do any of the proposed changes but I guess most of them have clear benefits. I am also not the first
> > to suggest them. Point 1 was mentioned with the initial drop of the device runtime [0], but it was rejected for time reasons. Point 2
> > was recently discussed as a pressing issue in multiple reviews. Point 3 is a general observation as writing and reviewing code for the
> > openmp sub project is unnecessarily hard for LLVM developers due to the different coding style.
> > 
> > Proposed structure:
> > In order to ease the reuse by new devices we should have a common core with device independent logic, e.g., in
> > openmp/ibomptarget/deviceRTLs/common
> > including an interface that declares all device specific methods needed by the core logic. The interface is then the
> > only thing implemented in the device subfolders, e.g., 
> > openmp/ibomptarget/deviceRTLs/nvptx, openmp/ibomptarget/deviceRTLs/amdgpu, ...
> > To get to this goal, all device specific code has to be extracted from the core logic. The prototypes below show that this
> > is fairly easy to do.
> > 
> > 
> > Feasibility and prototypes:
> > To showcase the direction I would like is to move to I "redesigned" three files (out of ~20) with the above goals in mind. The patches
> > can be found here:
> > https://reviews.llvm.org/D64217 
> > https://reviews.llvm.org/D64218 
> > https://reviews.llvm.org/D64219 
> > Note that there is a vast design space even if we agree to the above three goals. As a consequence, I'd like us to use the patches to
> > discuss general design decisions not specific ones until we agreed on a path forward.
> > 
> > 
> > Please let me know what you think,
> > Johannes
> > 
> > 
> > 
> > [0] https://reviews.llvm.org/D14254#949985 
> > 
> > 
> > ---------------------------------------
> > Johannes Doerfert
> > Researcher
> > 
> > Argonne National Laboratory
> > Lemont, IL 60439, USA
> > 
> > jdoerfert at anl.gov
> > 
> 
> 
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20190705/6ead7d7d/attachment-0001.html>