This is the mail archive of the
mailing list for the GCC project.
Re: GSoC 2018: Hrishikesh Kulkarni has been selected to work on LTO dumping tool
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Hrishikesh Kulkarni <hrishikeshparag at gmail dot com>
- Cc: GCC mailing list <gcc at gcc dot gnu dot org>, Martin Jambor <mjambor at suse dot cz>, Martin Liska <mliska at suse dot cz>, Jan Hubicka <jh at suse dot cz>, David Edelsohn <dje dot gcc at gmail dot com>
- Date: Wed, 25 Apr 2018 10:05:58 +0200
- Subject: Re: GSoC 2018: Hrishikesh Kulkarni has been selected to work on LTO dumping tool
- References: <firstname.lastname@example.org> <CAL+0whSccC_Gv7XXhqYsKHR8-vd4co7i7vt82TwEg2+wtgM0eQ@mail.gmail.com>
On Wed, Apr 25, 2018 at 5:17 AM, Hrishikesh Kulkarni
> 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
> 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
> 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.
> On Tue, Apr 24, 2018 at 6:27 PM, Martin Jambor <email@example.com> wrote:
>> 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,