Re: GSoC

[Martin Jambor <mjambor@suse.cz>]

Hello Abhinav,

sorry for a very brief answer, I'm not much online during Easter (the
timing of the application deadline is a bit unfortunate in this regard).

On Sat, Mar 30 2024, Abhinav Gupta wrote:
> Hello GCC community,
>      Since resuming work for the GSoC proposal recently, I have made
> significant progress in understanding the code snippets provided by
> Mr. Jambor and delved into the libgomp folder, compiling random
> snippets in the examples folder and reading the IR. Building GCC from
> source has also provided me with a deeper understanding of its inner
> workings.
> I've also looked at the GOMP_target_ext function and its
> implementations for both the existing targets as pointed out by Mr.
> Schwinge, these config folders have also given me an understanding of
> what is actually expected for this project, however I need some
> clarity regarding a few things-
>
> The GOMP_* functions calls for different targets: I need further
> assistance to understand how they should be implemented for the host
> machine, I am aware that this is exactly what the project is, I am
> just looking for a start point.

Look at functions with names starting with GOMP_OFFLOAD (such as
GOMP_OFFLOAD_run) in files in src/libgomp/plugin/*.c - those are the
things you'll need to implement but instead of setting up a GPU and
talking to AMD HSA or Nvidia CUDA you'll be setting up a new process and
communicating with it.

The entire list of functions that a plugin can have (probably not all
have to be implemented) is in struct gomp_device_descr in libgomp.h.

>
> Host Fallback Mode: I came across mentions of a host fallback mode in
> the offloading Wiki page and as you mentioned that there is already a
> oacc-host.c api. Could you please provide more clarity on whether this
> existing feature can be repurposed for offloading to a separate
> process on the same host? If not, could you elaborate on what exactly
> the host fallback mode is and how it differs from the proposed
> offloading mechanism?

Partially.  The host fallback means that, for one reason or another
(most commonly because the machine does not have any accelerators to
which it can offload), the OpenMP run time simply runs the target
regions on the CPU, almost as if it was not there (but there are
caveats, of course).

Which means that the outlined regions can be compiled basically as they
are for host fallback (though doing it with the same compiler will be
funny), on the GOMP side, things will need to look very differently.

I hope this helps,

Martin


>
> Thanking you
> Abhinav
>
> On Fri, 15 Mar 2024 at 03:54, Thomas Schwinge <tschwinge@baylibre.com> wrote:
>>
>> Hi Abhinav!
>>
>> Thanks for your interest in contributing to GCC, and thanks to Martin for
>> all the information you already provided.  Just a bit more, to get you
>> started on developing a proper project proposal:
>>
>> On 2024-03-13T14:54:52+0100, Martin Jambor <mjambor@suse.cz> wrote:
>> > On Tue, Mar 12 2024, Abhinav Gupta wrote:
>> >>     I looked at all the links you provided in the reply and read the
>> >> paper cited on the GCC page for GSoC. I also looked into the rust
>> >> frontend project during this time, and the Offloading project
>> >> interests me more, so I will focus solely on it in the remaining seven
>> >> days before the deadline for GSoC application submission.
>> >
>> > AFAIU, in five days (from now) the application period *opens*, the
>> > deadline is 2nd April.  Still it is good idea not to lose any time.
>>
>> Indeed, no rush yet.  :-)
>>
>> >> Are there other resources I can look at to better understand the whole
>> >> process?
>>
>> At some point, no too late, you should spend some time on learning how to
>> build GCC, and run the test suite.
>> <https://gcc.gnu.org/wiki/SummerOfCode> and
>> <https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development> have
>> some pointers to get started.  If you have specific questions, we're
>> happy to help, of course.
>>
>> >> Reading the git commit on the website is proving to be very
>> >> slow.
>>
>> Yes, that's not going to be necessary.
>>
>> >> I think the git commit about Intel MIC would be like a
>> >> "template" in loose terms
>>
>> Right, that's in fact a very good description.  The idea here is not to
>> bring back the whole Intel MIC emulator, but something very much simpler.
>>
>> >> to implement the host-ISA mode at least, but
>> >> for the libgomp plugin, I need a better understanding.
>>
>> Find existing libgomp plugins as 'libgomp/plugin/plugin-*.c'.  The
>> 'GOMP_OFFLOAD_[...]' functions implement the entry points, the offloading
>> plugin API.  Actually also the very simple 'libgomp/oacc-host.c' should
>> be helpful.  That's essentially the API you need to care about (for
>> OpenACC; but OpenMP 'target' also won't require much more, for a start).
>>
>> Make some thoughts (or actual experiments) about how we could
>> use/implement a separate host process for code offloading.
>>
>> And otherwise, as Martin said:
>>
>> > You need to understand how OpenMP programs are internally represented.
>> >
>> > Look at the following (hopefully correct, at least as long as you try it
>> > on a system without any Offloading enabled) simple testcase for OpenMP
>> > target construct:
>> >
>> > ----------------------------------------------------------------------
>> > #include <stdio.h>
>> >
>> > volatile int v = 1;
>> >
>> > int main (int argc, char **argv)
>> > {
>> >   int i = v;
>> >
>> > #pragma omp target map(to:i)
>> >   {
>> >     printf ("OpenMP target hello world, i is: %i\n", i);
>> >   }
>> >
>> >   return 0;
>> > }
>> > ----------------------------------------------------------------------
>> >
>> > and compile it with:
>> >
>> >   gcc -fopenmp omptgt-hello.c -O2 -fdump-tree-optimized
>> >
>> > and then look at the generated optimized dump.  This should give you an
>> > idea how OpenMP regions are internally represented (as outlined
>> > functions) and how calls into libgomp, the run-time library doing a lot
>> > of the magic, look like.
>> >
>> > You can try to do more similar exercises with more OpenMP testcase which
>> > you can find in sub-directory libgomp/testsuite/libgomp.c of in the GCC
>> > repository.
>> >
>> > And then you should perhaps have a look into libgomp itself (you'll find
>> > it in libgomp sub-directory) how GOMP_target_ext is implemented - though
>> > don't worry if you don't understand many of the details, it is complex
>> > stuff.  At this point hopefully more of the contents of the Offloading
>> > wiki page will make sense.
>> >
>> > Again, ask on the mailing list if you have any specific questions.
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> >> On Thu, 7 Mar 2024 at 20:37, Martin Jambor <mjambor@suse.cz> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> On Wed, Mar 06 2024, Abhinav Gupta via Gcc wrote:
>> >>> > Dear GCC Community,
>> >>> >     I hope this email finds you well. My name is Abhinav Gupta. I am a
>> >>> > 3rd-year student at IIT Tirupati pursuing a bachelor's degree in
>> >>> > computer science and engineering. I am writing to express my interest
>> >>> > in contributing to the GCC project under GSoC.
>> >>>
>> >>> We are very happy that you find contributing to GCC interesting.
>> >>>
>> >>> > I am interested in two projects - Offloading to a separate process on
>> >>> > the same host, I am already working in parallel computing,
>> >>> > specifically parallelising tensor algorithms using various techniques
>> >>> > as part of my research project at IIT Tirupati. Although this is not
>> >>> > directly related to compilers, I will be able to get going with the
>> >>> > project quickly.
>> >>>
>> >>> I'd personally very much like to see this project implemented.  There is
>> >>> a lot of information on offloading at
>> >>> https://gcc.gnu.org/wiki/Offloading
>> >>>
>> >>> To give you a bit more context where the idea comes from, it was first
>> >>> thought of in email thread starting with
>> >>> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603984.html and
>> >>> the patch that was "scrubbed" from the email archive eventually became
>> >>> commit
>> >>> https://gcc.gnu.org/cgit/gcc/commit/?id=e4cba49413ca429dc82f6aa2e88129ecb3fdd943
>> >>>
>> >>> I hope these pointers will further help help you find out where to look
>> >>> when planning the project.  If you need more help, please feel free to
>> >>> ask (I'm CCing Thomas who then is perhaps best placed to answer).
>> >>>
>> >>> > The second project is Rust Front-End - both the BIR location support
>> >>> > and rustc testsuite adapter are of interest to me,
>> >>>
>> >>> Please note that Rust-GCC projects are a bit special in the sense that
>> >>> they are often discussed primarily on Zulip of the gcc-rust team:
>> >>>
>> >>> https://gcc-rust.zulipchat.com/
>> >>>
>> >>> So you may want to reach out to them there as well.
>> >>>
>> >>> > having worked on
>> >>> > compiler front ends as part of my college's compiler design course
>> >>> > combined with my experience in working with large libraries written in
>> >>> > C++ (such as CTF) I believe that these two projects are something that
>> >>> > I can do.
>> >>>
>> >>> You seem to be quite ready!
>> >>>
>> >>> >
>> >>> > Proposed Timeline:
>> >>> > I can start working as soon as my end-semester exams finish, i.e. 9th
>> >>> > May 2024, and continue to work for however long it requires me to
>> >>> > complete the project.
>> >>> > Week 1-2 -> Knowing the existing code and understanding how it works.
>> >>>
>> >>> Right, but please try to do a bit of this, at least on the high level,
>> >>> also now when preparing the proposal.  There will be lots to learn in
>> >>> the first weeks even so.  Mainly because...
>> >>>
>> >>> > Week 3-8 -> Working on the implementation of whichever project we
>> >>> > decide to move forward with
>> >>> > Week 9-12 -> Testing and creating understandable documentation for the same.
>> >>> >
>> >>> > This is a very rough timeline,
>> >>>
>> >>> ...eventually the milestones in the application will have to be more
>> >>> specific, mainly to demonstrate you have basic understanding of the
>> >>> proposed project.
>> >>>
>> >>> > and I will refine it further as we
>> >>> > discuss the project idea. This email is more of a call for guidance
>> >>> > than an application, and I would appreciate any feedback you give me.
>> >>>
>> >>> This is a very good start.
>> >>>
>> >>> Good luck!
>> >>>
>> >>> Martin