Welcome GCC GSoC 2020 participants

Welcome GCC GSoC 2020 participants

[Martin Jambor]

Hello,

I am pleased to announce that three students will be working on GCC or
GCC-related Google Summer of Code (GSoC) projects in 2020:

 - Giuliano Belinassi will be working on "Automatic Detection of
   Parallel Compilation Viability."  This project will be mentored by
   Richard Biener and Jan Hubička.

 - John Ravi will work on "General Jobserver Client/Server Library" and
   be mentored by Martin Liška and Nathan Sidwell.

 - Tony Sim has embarked on " Implementing the OMPD interface" in
   libgomp, his project will be mentored by Jakub Jelínek and myself.

I'd like to congratulate all of them for putting together very solid
proposals and wish them best of luck with their projects.

All accepted students which do not already have one must request a
copyright assignment[1] as soon as possible.  Giuliano has it from last
year but I suspect that John and Tony do not.  Please email the
following information to assign@gnu.org and they will send you the
assignment form for your past and future changes.  Use your full legal
name (in ASCII characters) as the subject line of the message.  The "the
program or package" is of course GCC.

----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]

[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]

[For the copyright registration, what country are you a citizen of?]

[What year were you born?]

[Please write your email address here.]

[Please write your postal address here.]

[Which files have you changed so far, and which new files have you written
so far?]
----------------------------------------------------------------------

Please report back to me when you have completed the process and also if
you encounter any issues and/or unreasonably long delays.

The GSoC program has now entered its "community bonding period" which
lasts until June 1st.  During this time you should get in touch with
your mentors unless you have already done so and probably start looking
a bit more at GCC in general.  Because GCC targets many computer
platforms, you may also find it very useful to get an account on the
compile farm[2] so that you can test your code on a variety of
architectures.  Last but not least, feel free to raise any question you
might have on an appropriate mailing list[3] or say hi to us on the gcc
development IRC channel [4].

If you have any concerns or questions regarding the organizational part
of GSoC 2020 or just don't know who else to reach out to, feel free to
contact me throughout the duration of the program.

Once more, congratulations and good luck!

Martin

[1] https://gcc.gnu.org/contribute.html#legal
[2] https://gcc.gnu.org/wiki/CompileFarm
[3] https://gcc.gnu.org/lists.html
[4] https://gcc.gnu.org/wiki/GCConIRC

Re: Welcome GCC GSoC 2020 participants

[y2s1982 .]

Hello Martin,

Thank you for a thorough reply. I have some updates and more questions for
you. I have put them inline.
In gist,
- FSF replied with signed assignment form; still working on getting Compile
Farm access
- Generated bunch of GIMPLE dump and looked at few of them
- I proposed some form of workflow and would like some suggestions
- I looked at documentations and clang repository for OMPD and have some
questions.

On Mon, May 18, 2020 at 11:32 AM Martin Jambor <mjambor@suse.cz> wrote:

> Hello Tony,
>
> sorry for not getting back to you last week.  Time seems to fly even
> faster now that I'm forced to work from home :-/  Furthermore, both me
> and Jakub have been preparing for a big OpenMP meeting that takes place
> this week.
>

Wow, is that meeting something I may attend? It sounds like an amazing
learning opportunity.


>
> On Tue, May 12 2020, y2s1982 . wrote:
> > Hello Martin and Jakub,
> >
> > This is Tony Sim. I am excited to report that I have been getting some
> > documentation out of the way in the past few weeks.
> > - I have submitted a signed application to assign@gnu.org. I had a corr-
> > -espondence with Craig and have submitted a signed document last
> Thursday.
> > I have not heard back since.
>
> Great.  The processing was likely to take some time but if they still do
> not get back to you this week, please ping them.
>

I got a reply from Craig yesterday with the form that has both signatures.
It seems that part is now complete.


>
> > - I have requested an account to the Compile Farm. I got a welcome email
> to
> > a cf mailing list, but I do not know how to log in to the web portal or
> get
> > the SSH key to the servers. I never had a chance to assign a password nor
> > do i get a reply when I click on the "Lost Password" button. Should I
> > request for it again?
>
> I requested an account at the compile farm so long time ago that I do
> not remember the process.  Some sort of password can be re-set at
> https://cfarm.tetaneutral.net/ but as far as I can remember it is only
> needed to upload your public SSH key.  Please reach out to admins as
> described at https://cfarm.tetaneutral.net/tickets/ if you still cannot
> access your account.
>
> By the way, you don't "get" an SSH key, you upload the public part of
> the one you have generated yourself.
>

Oh, that makes sense: private keys shouldn't be shared. I do have a public
key, so I will share it when given the opportunity. I will reach out to the
Compile Farm later this week to inquire more on the progress of the
application.


>
> > - I have said greetings on IRC. I had two replies :) I haven't used IRC
> for
> > some years, and am trying to get my client to work exactly as how I would
> > like it
>
> Good.  This morning I have seen your last messages in the IRC log... and
> again, sorry for not getting back to you earlier.  Anyway, I hope that
> you got some of the questions you asked answered, and please ask again,
> even via email, if some still remain.  The time zone difference might
> work against us (both I and Jakub are on Central European time) but IRC
> tends to be a valuable tool nevertheless.
>
> About "how do I contribute" question you asked on IRC: I think it's
> going to take a little while before we get to that but once you have the
> FSF copyright assignment and something to contribute, we'll get you an
> account allowing you to commit after approval directly to the upstream
> repo - after approval means once your patch has been officially approved
> by the respective maintainer on the gcc-patches mailing list.
>
> At this point, I'd suggest that you simply clone our git repo and start
> experimenting.  Patch-via-email is likely to be the most used way of
> discussing code.  At some point we'll probably need a branch, that can
> initially sit either on gcc git server or anywhere else, really.  There
> is a mirror both at gitlab (https://gitlab.com/x86-gcc/gcc) or github
> (https://github.com/gcc-mirror/gcc) and many other git hosting services,
> for example.  Whatever fits your philosophical or practical preferences.
>

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. I also would like to know how often I should pull from
upstream to keep the fork up to date.  I would also welcome any suggestions
on improvements or changes to the overall process.


>
> > - and have been completing various paper work for GSoC, my school, and
> > other preparations to get started with the project.
> > Now, looking at the list of todo's in your email, I feel that I should
> get
> > in touch with my mentors and learn the ropes in preparation to the June 1
> > start.
>
> Sure.  First and foremost, please note that Jakub is the primary mentor
> for this project.  Jakub not only suggested the OMPD project idea but he
> is also the main maintainer of everything OpenMP related, he wrote a lot
> of the code himself and he is the principal architect of OpenMP in GCC.
>

Wow. I saw some of his blog posts, but it still baffles me how such thing
can be done from ground up. Just, wow.


> I will be an also-mentor, mainly because Google asked us to have more
> than one in this Covid-stricken year.  I have contributed a bit OpenMP
> code in the past and I should actually come back to it in a few days,
> but my involvement is much much smaller.  Nevertheless, I will do all I
> can to help you with any particular problem or to get you started.  But
> sometimes I might also struggle and please note that Jakub has to agree
> with all architecture-level decisions - even if they happen to be my
> idea :-)
>
I appreciate any suggestions, nonetheless :)

>
> I know that this delayed response might suggest otherwise, but email
> will be the main communication method for the project.  I believe Jakub
> strongly prefers email too, perhaps even more than I do.
>

I am comfortable with email. The community has been very generous on IRC
front, too, so I guess I will use both methods.


>
> More often than not it will be a good idea to CC the gcc mailing list on
> any email regarding the project.  It is not just the two of us who can
> help you with issues.  We also generally prefer working in the open.
>

Okay. I have CC'd the gcc mailing list. I hope I chose the correct one.


> 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?


> >
> > As the next step, I planned on following the instructions on
> > https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply. I also remember
> > suggestions that I should learn to read the dump files, which is going to
> > be the second things I will try out.
>
> OK, all very important, how is it going?
>
> In particular, look at (selected few) libgomp testcases in
> libgomp/testsuite/libgomp.c/ (let's focus only on C for now).  So after
> you've built gcc (remember to disable bootstrap and stuff), enter the
> "x86_64-pc-linux-gnu/libgomp/" subdirectory within your build directory
> (assuming you are on an x86_64) and run:
>
>   make -j -k check RUNTESTFLAGS="c.exp"
>
> and wait for the tests to be run which can take quite a while.  After
> they are, inspect the generated file in testsuite/libgomp.log which
> contains (among other things) the exact command lines used to compile
> the testcases.  Compile them yourself, add dumping options (I think the
> most interesting for you are -fdump-tree-original -fdump-tree-gimple
> -fdump-tree-omplower -fdump-tree-ompexp -fdump-tree-ssa and especially
> -fdump-tree-optimized), inspect the dumps and start asking questions.


I had built gcc but without disabling bootstrap. I read up on it, and was
wondering what was the need for disabling it. Is it to save time on
compilation by not compiling the entire gcc? or is there some other reasons?
Also, I tried compiling one of my old assignment from OpenMP with the flags
mentioned in the instruction.  The compiled code was using work-sharing to
perform reduction. It generated 255 files, and I observed .gimple,
.omplower, .ompexp, and .ompexpssa2.  I am still learning what just
happened to my code, of course :)  I wrote some of my findings in my blog:
http://shavedyak.blogspot.com/2020/05/debugging-with-gcc-gimple.html
I haven't looked at the optimized output, so I will look at that, too.  My
understanding is that each of the 255 files represents a transformation
from the .gimple file, each either translating the code to gimple or
optimizing before they are used to create the binary.


>
> 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?


>
> > I also feel that I should be reading up on OMPD documentation more
> > thoroughly, as well. Please feel free to give any suggestions on this
> path.
> >
>
> That's exactly right.  I currently can only point to the specification
> itself at openmp.org and to the only public implementation in (LLVM)
> libomp.  I personally have only had a superficial look at the former and
> none at all at the latter, so cannot provide much advice at this point.
> But this is the point where the actual project work starts ...so feel
> free to ask yet more questions.
>
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.


>
> > Furthermore, since this is supposed to be about community bonding, I was
> > wondering if there's any suggestions you might have for me in this
> regard.
>
> Please be persistent if people fail to respond to you for a long time :-)
> Ping me or Jakub if we have not replied for a few days.  Ping your
> patch on the mailing list if it has not been reviewed for two weeks.  It
> unfortunately can happen that we keep postponing a reply for a few days
> too many.
>
Okay. I will keep that time frame in mind.  Also, are there any suggestions
to the work schedule defined in my proposal? Should I change anything from
it?

>
> >
> > I look forward to working with you and the community.
>
> This is going to be a very difficult project but I am very happy to see
> it getting started!  I wish you best of luck!
>
Thank you very much :)

>
> Martin
>
>
Cheers,

Tony Sim

Re: Welcome GCC GSoC 2020 participants

[Martin Jambor]

Hello Tony,

On Wed, May 20 2020, y2s1982 . wrote:
> Hello Martin,
> On Mon, May 18, 2020 at 11:32 AM Martin Jambor <mjambor@suse.cz> wrote:
>
>> Hello Tony,
>>
>> sorry for not getting back to you last week.  Time seems to fly even
>> faster now that I'm forced to work from home :-/  Furthermore, both me
>> and Jakub have been preparing for a big OpenMP meeting that takes place
>> this week.
>
> Wow, is that meeting something I may attend? It sounds like an amazing
> learning opportunity.

Unfortunately no, it is a meeting of representatives of "members of the
OpenMP Architecture Review Board" and is not opened to public.

>> On Tue, May 12 2020, y2s1982 . wrote:
>> > This is Tony Sim. I am excited to report that I have been getting some
>> > documentation out of the way in the past few weeks.
>> > - I have submitted a signed application to assign@gnu.org. I had a corr-
>> > -espondence with Craig and have submitted a signed document last
>> Thursday.
[...]
>
> I got a reply from Craig yesterday with the form that has both signatures.
> It seems that part is now complete.
>

Great, It is good to know this has been sorted out.

[...]

> Oh, that makes sense: private keys shouldn't be shared. I do have a public
> key, so I will share it when given the opportunity. I will reach out to the
> Compile Farm later this week to inquire more on the progress of the
> application.

Good.  Compile farm will only get handy once it gets to testing stuff
anyway (assuming you have a reasonable computer to work on).

[...]

>>
>> About "how do I contribute" question you asked on IRC: I think it's
>> going to take a little while before we get to that but once you have the
>> FSF copyright assignment and something to contribute, we'll get you an
>> account allowing you to commit after approval directly to the upstream
>> repo - after approval means once your patch has been officially approved
>> by the respective maintainer on the gcc-patches mailing list.
>>
>> At this point, I'd suggest that you simply clone our git repo and start
>> experimenting.  Patch-via-email is likely to be the most used way of
>> discussing code.  At some point we'll probably need a branch, that can
>> initially sit either on gcc git server or anywhere else, really.  There
>> is a mirror both at gitlab (https://gitlab.com/x86-gcc/gcc) or github
>> (https://github.com/gcc-mirror/gcc) and many other git hosting services,
>> for example.  Whatever fits your philosophical or practical preferences.
>
> 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.

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 also would like to know how often I should pull from upstream to
> keep the fork up to date.

I personally pull every Monday, sometimes every other Monday if I feel I
am particularly short of time.  As long as it does not cause any painful
merging issues, I'd suggest similar cadence.  If there are issues,
falling behind a few weeks is OK if it helps you focus, I think.

[...]

>>
>> I know that this delayed response might suggest otherwise, but email
>> will be the main communication method for the project.  I believe Jakub
>> strongly prefers email too, perhaps even more than I do.
>
> I am comfortable with email. The community has been very generous on IRC
> front, too, so I guess I will use both methods.
>
>> More often than not it will be a good idea to CC the gcc mailing list on
>> any email regarding the project.  It is not just the two of us who can
>> help you with issues.  We also generally prefer working in the open.
>>
> Okay. I have CC'd the gcc mailing list. I hope I chose the correct one.

Yes, you indeed have.

>> 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.

>> > As the next step, I planned on following the instructions on
>> > https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply. I also remember
>> > suggestions that I should learn to read the dump files, which is going to
>> > be the second things I will try out.
>>
>> OK, all very important, how is it going?
>>
>> In particular, look at (selected few) libgomp testcases in
>> libgomp/testsuite/libgomp.c/ (let's focus only on C for now).  So after
>> you've built gcc (remember to disable bootstrap and stuff), enter the
>> "x86_64-pc-linux-gnu/libgomp/" subdirectory within your build directory
>> (assuming you are on an x86_64) and run:
>>
>>   make -j -k check RUNTESTFLAGS="c.exp"
>>
>> and wait for the tests to be run which can take quite a while.  After
>> they are, inspect the generated file in testsuite/libgomp.log which
>> contains (among other things) the exact command lines used to compile
>> the testcases.  Compile them yourself, add dumping options (I think the
>> most interesting for you are -fdump-tree-original -fdump-tree-gimple
>> -fdump-tree-omplower -fdump-tree-ompexp -fdump-tree-ssa and especially
>> -fdump-tree-optimized), inspect the dumps and start asking questions.
>
>
> I had built gcc but without disabling bootstrap. I read up on it, and was
> wondering what was the need for disabling it. Is it to save time on
> compilation by not compiling the entire gcc?

Yeah, the reason is compile time, but the point is not to avoid
compiling the "entire" gcc but rather not to compile it multiple times.
With bootstrap enabled, GCC is first built using the system compiler,
then again using itself to be optimized with its latest and greatest
optimizations passes and then again using the optimized version to
verify that the result is the same, bit-for-bit, to catch any errors in
the latest and greatest optimizations.

But you can also disable building stuff you don't need, in your case it
is for example enough to build only C and C++ front-ends using the
switch --enable-languages=c,c++ at configure time.  Later on you may
want to add fortran.

> Also, I tried compiling one of my old assignment from OpenMP with the flags
> mentioned in the instruction.  The compiled code was using work-sharing to
> perform reduction. It generated 255 files, and I observed .gimple,
> .omplower, .ompexp, and .ompexpssa2.  I am still learning what just
> happened to my code, of course :)  I wrote some of my findings in my blog:
> http://shavedyak.blogspot.com/2020/05/debugging-with-gcc-gimple.html
> I haven't looked at the optimized output, so I will look at that, too.  My
> understanding is that each of the 255 files represents a transformation
> from the .gimple file, each either translating the code to gimple or
> optimizing before they are used to create the binary.

Generally speaking, yes.  But it seems like you also used -fdump-rtl-all
option, which dumps the RTL intermediate representation of each function
after each pass.  RTL is a lower-level representation than gimple and is
very different from gimple.  I believe you can safely skip those now -
those tell you what lowest-level optimizations were performed, what
register allocation did etc.

Ditto for dumps generated by inter-procedural (IPA) passes and
associated (symbol table, call graph) infrastructure, produced with
-fdump-ipa-* options.  Those are whole different topic.

I suggested you looked at (selected) gimple dumps because I think those
are the easiest to read, not unlike a primitive C, and will show you
what GCC produces for various OpenMP constructs in a form that is easier
to grok than assembly.  You can have many gimple (tree) dumps generated
because there's one after each optimization pass.  But since your focus
is not on optimization, the last gimple dump called ".optimized" is
probably the only really interesting one for you.  That shows the final
gimple before it is translated to RTL (reduce optimization level to -O1
if optimizations like inlining confuse you).

And by the way, even though gimple representation of the same code is
very similar on different architectures, there is a myriad of details
(e.g. all the type sizes) which make it very much
architecture-dependent.

>>
>> 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 also feel that I should be reading up on OMPD documentation more
>> > thoroughly, as well. Please feel free to give any suggestions on this
>> path.
>> >
>>
>> That's exactly right.  I currently can only point to the specification
>> itself at openmp.org and to the only public implementation in (LLVM)
>> libomp.  I personally have only had a superficial look at the former and
>> none at all at the latter, so cannot provide much advice at this point.
>> But this is the point where the actual project work starts ...so feel
>> free to ask yet more questions.
>>
> 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.  

>>
>> > Furthermore, since this is supposed to be about community bonding, I was
>> > wondering if there's any suggestions you might have for me in this
>> regard.
>>
>> Please be persistent if people fail to respond to you for a long time :-)
>> Ping me or Jakub if we have not replied for a few days.  Ping your
>> patch on the mailing list if it has not been reviewed for two weeks.  It
>> unfortunately can happen that we keep postponing a reply for a few days
>> too many.
>>
> Okay. I will keep that time frame in mind.  Also, are there any suggestions
> to the work schedule defined in my proposal? Should I change anything from
> it?

IMHO the first 4-6 weeks look good, then we'll re-adjust.

>>
>> >
>> > I look forward to working with you and the community.
>>
>> This is going to be a very difficult project but I am very happy to see
>> it getting started!  I wish you best of luck!
>>
> Thank you very much :)

You're very welcome!

Martin

GSoC: OMPD conversation

[y2s1982 .]

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

Re: GSoC: OMPD conversation

[Martin Jambor]

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.

>
>>
>> 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?

OK, so me not noticing the email made that impossible, I'm afraid.  But
let's try the 2nd week.  Feel free to offer a suitable time.  I plan to
ping Jakub on IRC tomorrow and see if/when he'd be willing to attend.

>>
>> 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.

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.

> 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.


> 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.

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).

Martin

Re: GSoC: OMPD conversation

[y2s1982 .]

Hello,

On Thu, Jun 4, 2020 at 6:54 PM Martin Jambor <mjambor@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

Re: GSoC: OMPD conversation

[Jakub Jelinek]

On Fri, Jun 05, 2020 at 03:13:42PM -0400, y2s1982 . wrote:
> > > 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?

No.  We need our version of omp-tools.h in libgomp/ directory, which has
roughly the same content as the one from the OpenMP/sources repo, and
cross-checked against what the LLVM omp-tools.h.var contains, but with the
omp.h.in code formatting, similar style of multiple inclusion guard, license
boilerplate, the __GOMP_NOTHROW macros etc.

I think that should be your first coding task, the next one would be to
tweak libgomp/Makefile.am so that it also builds the libgompd shared
library, initially just containing a single function or two from the
interfaces and then you'd start adding further ones.

And yes, we'll need to also test it, which can be done by using gdb
with some python scripts that will load either libgomp.so directly shared library or
perhaps some wrapper library that will make it usable from python.

> 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.

This is just a temporary way how to express the taskloop complexity until
ompexp is done with it.  For taskloop, we need to be able to compute the
number of iterations in the encountering thread, which is what is
represented by the outer taskloop, then it behaves as an explicit task (many
of them in fact), for which we need the data sharing effects of it,
that is the middle construct which actually is really the same GIMPLE as
explicit task, just with an extra flag, and finally we need something in the
task that will iterate on all the iterations that were assigned to the task,
make sure the iteration variable is properly initialized etc., and that is
represented by the innermost taskloop.

What you care more about is what the ompexp dump looks like (or optimized
dump).

	Jakub