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 <mjam...@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 ass...@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
