[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    GSoC: OMPD conversation
From:       "y2s1982 . via Gcc" <gcc () gcc ! gnu ! org>
Date:       2020-05-31 20:08:38
Message-ID: CAKC_JtkRPkedTSfuC1r2j5xD+KaLg5na_E3goj2QAX=R-ouNDQ () mail ! gmail ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]