Re: GSoC: Implementation of OMPD

Re: GSoC: Implementation of OMPD

[Martin Jambor]

Hi Tony,

sorry for a late reply, things are a bit crazy recently.

On Sat, Mar 07 2020, y2s1982 . wrote:
> Hello everyone,
>
> My name is Tony Sim. In anticipation to planning for my last summer within
> my degree program, I am considering to take part in the Google Summer of
> Codes.  In particular, I would like to work on implementing OMPD for GCC
> and related programs.
>
> I have studied CPU and GPU parallel programming in the span of two
> semesters, which included OpenMP as a significant part of the curriculum. I
> am quite fascinated by its possibilities and would love a chance to learn
> more while tackling a real-world challenge.
>
> I would appreciate any additional information on the project.  It looks
> very interesting. Really, it sounds like something I wish I had when I was
> taking the course.
>

The OMPD project idea might be the most ambitious from the whole lot.
Basically, the goal is to come up with a prototype implementation of
chapter 5 of OpenMP 5.0 Specification
(https://www.openmp.org/specifications/), so that OpenMP programs
compiled with GCC can be debugged in GDB using OpenMP terminology.

In order to start you need to understand how OpenMP programs are
internally structured (compile some a few basic ones with
-fdump-tree-optimized and then examine the generated dump) and
especially familiarize yourself with the libgomp library that provides
essential run-time support to OpenMP programs.  Libgomp is part of GCC
project, see https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=libgomp.

The long-term goal is to implement that chapter 5 in libgomp, so that
internal structures of libgomp and the run program can be exposed with
this interface.  Of course, that would be too big a project for one
summer, so the immediate goal would be to come up with an implementation
of a subset that would behave well in a given set of contexts... and
either make it consumable by GDB or at the very least demonstrate that
it can be done.  Still a lot of work.

If you have any further questions, please feel free to ask.

Good luck with your GSoC!

Martin

Re: GSoC: Implementation of OMPD

[y2s1982 .]

Hello Martin,

I have replied in-line.

On Tue, Mar 24, 2020 at 7:36 PM Martin Jambor <mjambor@suse.cz> wrote:

> Hi Tony,
>
> sorry for a late reply, things are a bit crazy recently.
>

That's okay. Thanks for reaching back to me. I am still very interested.


> On Sat, Mar 07 2020, y2s1982 . wrote:
> > Hello everyone,
> >
> > My name is Tony Sim. In anticipation to planning for my last summer
> within
> > my degree program, I am considering to take part in the Google Summer of
> > Codes.  In particular, I would like to work on implementing OMPD for GCC
> > and related programs.
> >
> > I have studied CPU and GPU parallel programming in the span of two
> > semesters, which included OpenMP as a significant part of the
> curriculum. I
> > am quite fascinated by its possibilities and would love a chance to learn
> > more while tackling a real-world challenge.
> >
> > I would appreciate any additional information on the project.  It looks
> > very interesting. Really, it sounds like something I wish I had when I
> was
> > taking the course.
> >
>
> The OMPD project idea might be the most ambitious from the whole lot.
> Basically, the goal is to come up with a prototype implementation of
> chapter 5 of OpenMP 5.0 Specification
> (https://www.openmp.org/specifications/), so that OpenMP programs
> compiled with GCC can be debugged in GDB using OpenMP terminology.
>

This is music to my ears. I am eagerly reading up on the documentation,
starting from their section 5 that seems to cover OMPD in detail.


> In order to start you need to understand how OpenMP programs are
> internally structured (compile some a few basic ones with
> -fdump-tree-optimized and then examine the generated dump) and
> especially familiarize yourself with the libgomp library that provides
> essential run-time support to OpenMP programs.  Libgomp is part of GCC
> project, see https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=libgomp.
>

Okay, I will try that. I guess I will try out some simple for loop and
see.  Any particular sections or tips on reading the dump?


> The long-term goal is to implement that chapter 5 in libgomp, so that
> internal structures of libgomp and the run program can be exposed with
> this interface.  Of course, that would be too big a project for one
> summer, so the immediate goal would be to come up with an implementation
> of a subset that would behave well in a given set of contexts... and
> either make it consumable by GDB or at the very least demonstrate that
> it can be done.  Still a lot of work.
>

As you mentioned, the project seems ambitious, and one of the challenges
seemed to be setting a scope. Thank you for providing me with that
guideline.
So, if I may reiterate and make some more assumptions, the scope seems to
be: coming up with a proof-of-concept that may be replicated elsewhere to
complete the integration of OMPD.
This is exactly what I am interested in doing and gain valuable learning
experience while doing so.

>
> If you have any further questions, please feel free to ask.
>

I do have a question.
Debugging a program with OMP was challenging; if anything, the
race-condition alone made reproducing many bugs a probability issue.  I was
taught to give extra care on developing, optimizing, and debugging a
single-thread counterpart first before converting to an OMP application.
Would the OMPD make it possible for programmer to develop an OMP
application from ground-up, or would they still need to design the
single-threaded version first?


> Good luck with your GSoC!
>
> Martin
>

Re: GSoC: Implementation of OMPD

[Jakub Jelinek]

Hi!

I appreciate you are interested in this GSoC topic!

On Tue, Mar 24, 2020 at 09:18:50PM -0400, y2s1982 . via Gcc wrote:
> > The OMPD project idea might be the most ambitious from the whole lot.
> > Basically, the goal is to come up with a prototype implementation of
> > chapter 5 of OpenMP 5.0 Specification
> > (https://www.openmp.org/specifications/), so that OpenMP programs
> > compiled with GCC can be debugged in GDB using OpenMP terminology.
> >
> 
> This is music to my ears. I am eagerly reading up on the documentation,
> starting from their section 5 that seems to cover OMPD in detail.

Yeah, we are looking for the header file and a new shared library that GDB
or other debuggers will be able to dlopen and that will implement the OMPD
APIs.  That shared library will need to closely cooperate with the libgomp
runtime library (should have sources in the libgomp/ subdirectory and built
from its makefiles too), to agree on various details, like structure offsets
etc.
One possible way to implement it is just require that the OMPD library and
libgomp library come from the exact same source tree and same architecture,
perhaps using some hash or version number to verify it, another one is to
add some read-only data to the libgomp shared library which would contain
some version number and sizeof/offsetof values for whatever the OMPD library
will need, where we could bump the version number if significant internal
changes are done to the libgomp library which would make OMPD incompatible
and the rest caught by the other values, or it could use something like
https://infinitynotes.org/wiki/Infinity where libgomp would describe what
OMPD needs to know and OMPD library parse that.
The more independent the OMPD library is from the exact libgomp version, it
will be easier for users but more work.  Having it more independent will
e.g. allow a 64-bit debugger to dlopen 64-bit libgompd (or whatever the
library will be called) and debug not just 64-bit processes using OpenMP,
but also 32-bit ones.
Infinity notes certainly aren't a requirement and one could add that later,
while expressing whatever the library needs to know in some other form.

> > In order to start you need to understand how OpenMP programs are
> > internally structured (compile some a few basic ones with
> > -fdump-tree-optimized and then examine the generated dump) and
> > especially familiarize yourself with the libgomp library that provides
> > essential run-time support to OpenMP programs.  Libgomp is part of GCC
> > project, see https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=libgomp.
> >
> 
> Okay, I will try that. I guess I will try out some simple for loop and
> see.  Any particular sections or tips on reading the dump?

There are several dumps that are useful for understanding what's going on.
I'd recommend ... -fopenmp -fdump-tree-{gimple,omplower,ompexp,optimized}.
All the dumps are GIMPLE (the first two in high GIMPLE and last two in low
GIMPLE), which is GCC internal representation, but is quite close to C;
it uses SSA form, SSA names have versions with underscore and version number
appended to them (if it is just _123, then it is anonymous SSA name and
early in the function it has some declared type).
The gimple dump is the closest to the original source code, and is useful
to find out e.g. what OpenMP clauses have been there explicitly and what
have been added implicitly, omplower still has those clauses but already
has the data sharing and mapping clauses expanded to some code which passes
the values between the regions, adds privatized versions of the variables,
etc.  The ompexp pass then lowers the rest of the OpenMP constructs to
actual IL statements, outlines parallel/task/target regions, adds
library API calls etc.  And optimized dump is at the end of the GIMPLE
optimization pipeline, after many other optimizations.
OMPD will primarily describe the runtime library, so what you care most is
what API calls (usually GOMP_* functions) are called for the different
constructs and how it is implemented on the library side.

	Jakub