public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Hrishikesh Kulkarni <hrishikeshparag@gmail.com>
Cc: GCC mailing list <gcc@gcc.gnu.org>,
	Martin Jambor <mjambor@suse.cz>, Martin Liska <mliska@suse.cz>,
		Jan Hubicka <jh@suse.cz>, David Edelsohn <dje.gcc@gmail.com>
Subject: Re: GSoC 2018: Hrishikesh Kulkarni has been selected to work on LTO dumping tool
Date: Wed, 25 Apr 2018 08:13:00 -0000	[thread overview]
Message-ID: <CAFiYyc211qhER5h2kKT4vRMqT3iQsBjkOdhfT793Z_NQOsEMRQ@mail.gmail.com> (raw)
In-Reply-To: <CAL+0whSccC_Gv7XXhqYsKHR8-vd4co7i7vt82TwEg2+wtgM0eQ@mail.gmail.com>

On Wed, Apr 25, 2018 at 5:17 AM, Hrishikesh Kulkarni
<hrishikeshparag@gmail.com> wrote:
> Hi,
>
> Thanks a lot for giving me this wonderful opportunity to work with GCC
> under your guidance and mentorship (GSOC 2018).
>
> Just a few starting queries
>
>    1.
>
>    As a starting point to read lto-object file, is it sufficient to only
>    link with lto-object.c or shall I need other source files too ?

You will need a lot more source files - starting with libbackend.a is
probably easiest.  As said during the initial project discussion it
remains to be seen whether a fully standalone dump tool is
best or whether the actual work is to be done by lto1 and the dump
tool shall act merely as a driver around that and they communicate
via some special (set of) options to lto1.

IIRC we do not have any existing tool that builds trees or cgraph
nodes or reads gimple bodies, so picking pices that are required
is going to be "interesting" (and eventually will suggest some refactoring
to avoid pulling in unnecessary stuff).  You'll also run into issues expecting
some initialized global state.  So...

...for the first phase of experimenting with the code-base it's probably
easiest to add some testing option to gcc/lto/lang.opt and "do stuff"
within a if (flag_your_option) conditional from some point in
lto/lto.c:lto_main.

>    2.
>
>    Should the dump tool be under gcc or lto dir? Would I need to modify
>    only gcc/Makefile.in to add entry for building the dump tool or any other
>    Makefiles too ?

I'd say it most naturally would reside in gcc/lto/ and thus its Make-lang.in
would need to be adjusted.

>
> Also, I would proceed with copyright assignment as soon as I will receive
> the mentioned forms.
>
>
> Thanks,
>
> Hrishikesh
>
>
> On Tue, Apr 24, 2018 at 6:27 PM, Martin Jambor <mjambor@suse.cz> wrote:
>
>> Hello,
>>
>> I am pleased to announce that Hrishikesh Kulkarni will be working on
>> "Textual Representation of LTO Object Files (Textual LTO dump tool
>> project)" as his Google Summer of Code 2018 project.  I believe I write
>> on behalf of everybody in the GCC community when I congratulate him and
>> wish him success in the upcoming work.  Hrishikesh's mentors are Martin
>> Liška and Jan Hubička, but the plan is to have most of the conversation
>> about the project on the mailing list and so I would like to encourage
>> everyone to help him out here if they can.
>>
>> According to the schedule of GSoC, we have entered "Community Bonding
>> period" which lasts until May 14th (when the first out of three "coding"
>> periods begin).  Hrishikesh, Martin and Honza will take over from me in
>> suggesting what technical things you should study/play with, but I'd
>> like to request that you make sure you get an FSF copyright assignment
>> quickly (see https://gcc.gnu.org/contribute.html#legal).  David, I
>> assume that Hrishikesh does not have the assignment yet, can you please
>> send him the necessary forms?  Hrishikesh, please fill them is when you
>> get and send them to FSF.  If at any moment it will appear that the
>> process got stuck, please let me know sooner rather than later.
>>
>> On a general note, GCC was given two student slots which we requested
>> after receiving two high-quality student proposals.  Unfortunately,
>> Sebastiaan has withdrawn from GSoC 2018 before selection was announced
>> and so we "only" have one student this year.
>>
>> I'm looking forward to the new tool,
>>
>> Martin
>>

  reply	other threads:[~2018-04-25  8:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-24 14:45 Martin Jambor
2018-04-25  6:04 ` Hrishikesh Kulkarni
2018-04-25  8:13   ` Richard Biener [this message]
2018-04-28 18:22     ` Hrishikesh Kulkarni
2018-04-30 11:56       ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFiYyc211qhER5h2kKT4vRMqT3iQsBjkOdhfT793Z_NQOsEMRQ@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=hrishikeshparag@gmail.com \
    --cc=jh@suse.cz \
    --cc=mjambor@suse.cz \
    --cc=mliska@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).