public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Interest in GSoC Project (offloading to a separate process on the same host)
@ 2024-03-15  7:50 PRANIL DEY
  2024-03-19 13:08 ` Martin Jambor
  0 siblings, 1 reply; 2+ messages in thread
From: PRANIL DEY @ 2024-03-15  7:50 UTC (permalink / raw)
  To: gcc

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

Hello GCC Community,

I am Pranil Dey, a 4th year undergraduate student of the Indian Institute
of Technology Kharagpur currently pursuing a Bachelor's Degree in Computer
Science and Engineering. I am interested in contributing to the GCC
projects under GSoC, specifically the projects : "Offloading to a separate
process on the same host" and "Improve nothrow detection in GCC".
I have worked on inter process communication in college operating systems
projects which have helped me understand more about shared memory, pipes
and multithreading concepts. I have also taken compiler design theory and
laboratory courses as a part of my institute curriculum. In the lab we
designed a Tiny-C compiler (a subset of GCC). Although I have no experience
with big projects like GCC, I have built the codebase and am currently
trying to understand it further. I would like some pointers to start
understanding and contributing to these projects along with any
helpful resources/reading material for delving deeper into the relevant
topic. Any guidance on proposal formulation will also be appreciated
greatly.

Thank You,
--
Pranil Dey
Student of Indian Institute of Technology Kharagpur
Dept. of Computer Science and Engineering

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Interest in GSoC Project (offloading to a separate process on the same host)
  2024-03-15  7:50 Interest in GSoC Project (offloading to a separate process on the same host) PRANIL DEY
@ 2024-03-19 13:08 ` Martin Jambor
  0 siblings, 0 replies; 2+ messages in thread
From: Martin Jambor @ 2024-03-19 13:08 UTC (permalink / raw)
  To: PRANIL DEY, gcc

Hello Pranil,

We are delighted you found contributing to GCC interesting.

On Fri, Mar 15 2024, PRANIL DEY via Gcc wrote:
> Hello GCC Community,
>
> I am Pranil Dey, a 4th year undergraduate student of the Indian Institute
> of Technology Kharagpur currently pursuing a Bachelor's Degree in Computer
> Science and Engineering. I am interested in contributing to the GCC
> projects under GSoC, specifically the projects : "Offloading to a separate
> process on the same host" and "Improve nothrow detection in GCC".
> I have worked on inter process communication in college operating systems
> projects which have helped me understand more about shared memory, pipes
> and multithreading concepts. I have also taken compiler design theory and
> laboratory courses as a part of my institute curriculum. In the lab we
> designed a Tiny-C compiler (a subset of GCC). Although I have no experience
> with big projects like GCC, I have built the codebase and am currently
> trying to understand it further.

Great, you seem to be very well prepared!

> I would like some pointers to start
> understanding and contributing to these projects along with any
> helpful resources/reading material for delving deeper into the relevant
> topic. Any guidance on proposal formulation will also be appreciated
> greatly.

As far as the offloading to a separate process project is concerned, we
have had a brief discussion on this mailing list in the recent past,
have a look especially at
https://gcc.gnu.org/pipermail/gcc/2024-March/243462.html and
https://gcc.gnu.org/pipermail/gcc/2024-March/243478.html

As far as the nothrow detection project is concerned, let me quote Honza
Hubička from an email which, probably by mistake, did not reach the
mailing list:

----------------------------------------------------------------------
GCC EH works in a way that it marks statements that can possibly throw
(these can be calls or non-call exceptions) and assigns them to EH
regions.  EH regions are organized into a tree structure which describes
what types are caught and handled.

This data structure is in except.h / except.cc and can be dumped
before/after every pass (I believe iwth -fdump-tree-all-details)

For optimization we have two predicates - can_throw_internal and
can_throw_external which are used to detect notrhow functions and if
function is notrhow we can save EH tables and optimize EH hadnling code
(especialy EH cleanup regions calling implicit destructors that are
quite frequent).

What we miss the ability to track type of a given exception and detect
that given function handles all exceptions that it can possibly receive.
As a result such code leads to unnecesary cleanups later.

So the work is to make middle-end aware of it - is probably quite
easily detectable from calls to __cxa_throw which takes the type as
parameter.  Then we need to add propagation which will understand what
kind of exceptions are rethrown which will let us to deterine list of
all types possibly thrown by the function.

So I think good start is to look into the data-structure EH is
represented and look into detecting types of __cxa_throw.

The nothrow discovery currently lives in pure-const pass and is very
simple minded: if something in function apsses can_throw_external then
function can throw.  So in the next step the propgation will need to be
added here.
----------------------------------------------------------------------

Hope this help, if you have any specific issues you'd like to help with,
certainly feel free to ask here again.

Good luck!

Martin Jambor


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-03-19 13:08 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-15  7:50 Interest in GSoC Project (offloading to a separate process on the same host) PRANIL DEY
2024-03-19 13:08 ` Martin Jambor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).