Hello, On Thu, Jun 4, 2020 at 6:54 PM Martin Jambor <mjam...@suse.cz> wrote:
> Hi, > > On Sun, May 31 2020, y2s1982 . wrote: > > Hello team, > > > > I just wanted to give an update to my current progress. I spent most of > the > > time looking over OMPD documentation again and studying LLVM's approach > to > > it. > > > > thanks a lot, sorry about replying this late again, unfortunately I > missed your email on Monday and only noticed it yesterday. > > [...] > > >> > >> 1) We are used to reviewing patches in our email clients and prefer it > >> to reviews in web-based tools. I have quite a lot of customizations > >> in place that I am used to and so prefer it to > >> one-method-fits-everyone web tools. > >> > > I understand. This kind of information is exactly what I wanted to know > so > > I can adjust my work process to fit the community needs. My I follow the > > above process of making PR but also create a patch using 'git diff' > command > > and share that with the mailing list? > > yeah, sure, although I think people usually use git format-patch. > Oh okay. This is the exact kind of information I was looking for :D. I was looking at the command, too, but I wasn't sure how exactly to use it. I will look more into it and learn. > > > In an effort to understand how I might go about starting the OMPD > project, > > I spent some time studying LLVM's attempt. Following are my findings and > > some questions. > > > > The LLVM's repository for OMPD development is at this github repo > > <https://github.com/OpenMPToolsInterface/LLVM-openmp/tree/ompd-tests>, > > under the branch ompd-test. > > The OMPD documentation > > <https://www.openmp.org/spec-html/5.0/openmpse43.html#x242-16540005.1> > states > > that the omp-tools.h be available. > > I believe it is > https://github.com/OpenMP/sources/blob/master/include/omp-tools.h > > It should be referenced somewhere from the openmp.org but possibly > actually isn't. > Hmm, does this mean the file should be or is already imported via autoconf? I also assume I should have at least a dummy definition for all declared prototypes when the header file is included. > > > The closest thing to this I found > > was in this > > .var file > > < > https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/ompd-tests/runtime/src/include/50/omp-tools.h.var > >, > > though I am not familiar enough to understand how this translate to > > omp-tools.h file later. After this, things got a little more > interesting. > > First, they seem to be using GNU gdb as the debugger. From there, their > older > > attempt > > < > https://github.com/OpenMPToolsInterface/LLVM-openmp/tree/ompd-tests/libompd/gdb-wrapper > >, > > stored > > in a folder called "gdb-wrapper", seems to work around with creating a > > C/C++ wrapper. This seems to be in the process of being replaced with > > gdb-plugin idea, as represented in this git issue > > <https://github.com/OpenMPToolsInterface/LLVM-openmp/issues/77> and > their > > current CMakeList.txt > > < > https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/ompd-tests/libompd/CMakeLists.txt > >. > > The gdb-plugin > > < > https://github.com/OpenMPToolsInterface/LLVM-openmp/tree/ompd-tests/libompd/gdb-plugin > > > > seems > > to rely on python to implement OMPD. > > So by now you may know quite a bit more about LLVM's OMPD effort than I > do but it rather seems like they use the python gdb scripts to call into > a python module written in C - which in term uses OMPD interface to get > information about the debugged program - in order to provide the user > with useful OpenMP context. I only looked at them quickly but they do > not look anything like an implementation. > > Yes, they do call gdb via Python. I wasn't sure if that's what I was supposed to do or not. Good thing you clarified that for me just now :D > > > For example, other than the fact that > > most of the code in the folder is written in python, the ompdModule.c's > > _read() > > < > https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/3b6c06e354ef1e59da22778a9033d87ed0e3b19d/libompd/gdb-plugin/ompdModule.c#L504-L534 > >, > > which corresponds to ompd_callback_memory_read_fn_t typedef > > < > https://www.openmp.org/spec-html/5.0/openmpsu209.html#x264-17550005.4.3.2> > > defined > > in the OMPD documentation, creates and manipulates PyObject throughout > the > > function implementation. > > Right. But looking at the python scripts I really tend to think they > are simply OMPD users. > > > > > I am left with a couple of questions: > > First of all, they seem to be working with gdb to provide OMPD solution > in > > forms of wrapper/plugin. Can we use this code, too? What kind of issues > do > > we have with licensing? > > We do take the sanitizer run-time library code from LLVM upstream, so I > think it is possible, in principle. but... > > > > > Secondly, the LLVM team started from C/C++ wrapper and moved on to Python > > implementation. > > ...again, maybe I'm misunderstanding you, but the implementation is not > in python. For example, the first function in the OMPD spec, > ompd_initialize, is implemented in libompd/src/omp-debug.cpp. > Thank you for pointing that out. I was so focused on looking at callback functions that I didn't look at the more broad picture. > Also, the LLVM effort should probably only serve as a reference. The > main design question is how to implement the interfaces from the OMPD > spec in libgomp (or how to make an OMPD component/tool get the required > info from libgomp). > I agree. > > Martin > This week, I spent more time on understanding libgomp and gimple. For libgomp, I started from the GOMP_parallel() and followed a chain of function calls, macros, and various structs used. The structs were the most interesting of the three, and I still feel I have much to digest. I also spent a few days looking at gimple. Just to be sure, is the following progression correct? .gimple -> ... -> .omplower -> ompexp -> ompexpssa2 -> ... -> optimized The style of code seems to transition a bit between omplower and ompexp. Between the gimple documentation and just reading through the gimple files, I think I have a rough understanding of how things go. I do have few questions, likely with much more to come: 1. When compiling for-1.C test file with -fdump-tree-all, I came across the variable declaration like this in .gimple file: struct I & D.3626; In C++, I would think that's some sort of reference, but then it would need to be defined at declaration. The declaration disappears in .omplower though the variable is still used. 2. When compiling taskloop-5.C with the same flag, in .gimple file, I saw a for loop that seems to appear twice. Original: #pragma omp taskloop firstprivate (b, f) for (int i = 0; i < 30; i++) { .gimple: #pragma omp taskloop private(D.2631) for (D.2631 = 0; D.2631 < 30; D.2631 = D.2631 + 1) { { #pragma omp taskloop firstprivate(f) firstprivate(b) private(i) { #pragma omp taskloop for (i = 0; i < 30; i = i + 1) { I was hoping someone could explain why this happened so I can better understand how libgomp broke down the problem. Cheers, Tony Sim
