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.
> > > > If it is all the same, and since I am familiar with working on github, > may > > I work on github? I took the liberty of creating the fork of gcc-mirror > to > > my account. I would like to create a major develop branch within the > fork, > > and create minor develop branches from that branch. I would also like to > > plan out my tasks using their Issue tracking system. The minor develop > > branch code would be reviewed via PR by any interested parties, > > particularly Jakub, after which it would be squash-merged to the major > > develop branch of the fork. We can discuss further on the interval for > the > > patch-via-email process to merge the code to upstream, which I assume > would > > happen when the code reaches certain maturity, or at least at the end of > > this project. > > If that is how you like to work, I guess we can try it out. Just please > keep in mind that: > > 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? > > 2) Do not spend too much time thinking about how to organize the > project. The time is better spent actually thinking about the > project itself, particularly because I expect this one to entail a > lot of experimenting with an occasional dead end. > I understand. I just thought this discussion belonged to me getting to know how to work with the community and therefore fit the community bonding period theme. I am very excited to get to actually work, too. > > >> Having said that, if you'd like to do a hangouts video call to say hello > >> to each other and perhaps to discuss some issues with setting up your > >> work, I personally am definitely happy to do that too. As a regular > >> communication tool, I did not find videoconferencing to be very useful > >> in the past (but I guess I can be persuaded to try again). > > > > Hmm. In my last coop that ended during pandemic, we used the video > > conferencing tool to do daily stand-ups so the team can keep tabs on how > > different parts of the project is going and give suggestions as needed. A > > little off-topic, but how often would you like to discuss my progress of > > the project? > > So... ideally the stream of emails discussing the overall approach, > followed by a stream of patches and reviews would make it completely > unnecessary to ask you for some kind of regular status reports. > Nevertheless, if some task takes you more than a 4-5 work-days in which > you don't get back to us, please send us a quick summary of what you > have been working on. This arrangement of course means that you need to > reach out to us if you believe you are stuck, so please do. > > But let me reiterate that I am willing to try a videoconference or two > if you think it would be useful at any point. > Would it be nice to have a face-to-face conversation perhaps in the first week of June? Perhaps open to any interested community member to discuss the beginnings of the OMPD? > > >> > >> Dumps will show you what the compiler produces but most of the work in > >> this project will probably be done in the run-time library libgomp. So > >> look at its source, the generated dump files should show you what are > >> the entry points and when they are called. Please make sure you > >> understand how the library works for simple OpenMP (example) programs. > >> Ask more questions. > >> > > I will try compiling the test cases you mentioned and try to understand > the > > gimple more in depth. I will also try to see which part of the libgomp is > > making the translation. Is it correct for me to assume that libgomp is > all > > about reading C code and manipulate GIMPLE? > > > > No, GCC, the compiler, reads C and then goes through various stages of > intermediate representations of the C code, one of which is gimple, > optimizes it and produces an assembly. > > If that C file contains OpenMP directives (and you compile with > -fopenmp) many of those are converted in one way or another into calls > into the "GNU offloading and multi-processing (run-time) library:" > libgomp. It used to be just GNU OpenMP library but now it is also the > run-time library for OpenACC. > > For example, #pragma omp parallel is compiled in a way that the body of > the construct is outlined into a special artificial function and the > construct itself is compiled into a call to a function GOMP_parallel, > with a reference to the function with the body passed in one of the > parameters. In gimple optimized dump, the function is called > __builtin_GOMP_parallel which I admit is slightly confusing, but it is > the same thing - and the concept should be well visible in the dump. > > GOMP_parallel is a function in libgomp. Grep-ing for it in the libgomp > subdirectory finds it in parallel.c. From the dump you should have good > idea what it receives in its parameters. Reading a large chunk of > libgomp source code starting there - and perhaps at other such entry > points - is probably a good idea. > I think I will study the libgomp library first week of June. I will keep the above in mind as I look over the code. Now that I have more understanding of OMPD, I aim to find relevant functions that I could use for OMPD. > > I skimmed through the documentation to familiarize with the interface. I > > would have to read more on it as I go through the development. > > I also looked at the clang project. I could see how some of the document > > was used to create headers and constants. What I didn't get is their > > references to gdb: does that mean something different in clang or is that > > referencing GCC's gdb? An entire folder is dedicated to gdb-wrapper, for > > example, and a commit history also references gdb. > > I can only guess they indeed refer to GNU gdb. > 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. 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. 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. 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? Secondly, the LLVM team started from C/C++ wrapper and moved on to Python implementation. Is this decision something I should consider and look further into? Or by working more closely with the GNU codebase, would I have a more efficient option? Any suggestions would be welcomed :) Tony
