From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18553 invoked by alias); 13 Mar 2018 04:30:49 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 18543 invoked by uid 89); 13 Mar 2018 04:30:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:g6y-Eoy, H*f:sk:g6y-Eoy, H*c:alternative X-HELO: mail-oi0-f47.google.com Received: from mail-oi0-f47.google.com (HELO mail-oi0-f47.google.com) (209.85.218.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 13 Mar 2018 04:30:46 +0000 Received: by mail-oi0-f47.google.com with SMTP id t185so14253367oif.6 for ; Mon, 12 Mar 2018 21:30:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+39+1A+GAEp7Z0GGJxr8CERL4iFIpBqtfaYYrBSsiac=; b=hJeGNKFzUAHubIBZGIGppizYsW9oC8MjF5krnnzqET5bpNZJ62NeH09UFaE4CJa3vr qd8P1MHDp496N39zy/VzebeFm82/zvsGVzozOLxCQl8WdlpwtEIFFFG8Q9B758ezSifD Q6zSyYW3NFrRtBUWz9B51VzHCdPvPNVi54dqr4VYJLLpw/CCwlHeMW2R81CQzfHC5Hiz ZKcS8KBSDnhQfndr/hKpNPoJ2txGG4ZrIGZqJU33VPMyfXTqfntTrtYir8w+5cGDx81p euyYGvP6P+ui+GJKxIWAe1/wfmgsIv58deeex70GKugEaBL/o+01NKNJx7vE3j0Jyz12 qxQQ== X-Gm-Message-State: AElRT7HrTyV70Prs8rJPfJ6XBAmfk09Km7zx6z6aq6Juqp4yE2l2r+lO k9LlxgxBT1H+Zu4NMGzmkvRpmzzBKr0HbK54DNsrn3Xr X-Google-Smtp-Source: AG47ELuJd/LD7NajYgMVEPh+fL+VM05b25oOS4MQv/vcUZB1Y5YgihwcoCAyVcCfCUWyt2cSquw8CQ2hKP2sWb94GXI= X-Received: by 10.202.252.67 with SMTP id a64mr6770960oii.256.1520915444284; Mon, 12 Mar 2018 21:30:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.62.194 with HTTP; Mon, 12 Mar 2018 21:30:43 -0700 (PDT) In-Reply-To: References: <20180302130120.GA21280@kam.mff.cuni.cz> <20180306150201.GB36111@kam.mff.cuni.cz> <20180306152907.GA63339@kam.mff.cuni.cz> From: Hrishikesh Kulkarni Date: Tue, 13 Mar 2018 04:30:00 -0000 Message-ID: Subject: Re: GSOC 2018 - Textual LTO dump tool project To: GCC Development Cc: =?UTF-8?Q?Martin_Li=C5=A1ka?= , Richard Biener , Martin Jambor , Jan Hubicka Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00149.txt.bz2 Hi, Thanks. I have tried to incorporate suggestions and prepared a revised draft of proposal for GSOC. Please find the same attached herewith. Your suggestions in regard with this draft would definitely help me to improve it further for submission. Drive link to Draft Proposal: https://docs.google.com/document/d/1-jYwwDWsHQwMaxVsHFBrJ9EiCAev7ljTDLS1xMw= vK5w/edit Regards, Hrishikesh On Mon, Mar 12, 2018 at 4:45 PM, Richard Biener wrote: > On Sun, Mar 11, 2018 at 8:23 PM, Hrishikesh Kulkarni > wrote: > > Hi, > > > > Greetings! Please find my draft proposal for GSOC attached herewith. I = am > > very grateful to all of you for your inputs, suggestions and directions. > I > > have tried to assimilate these inputs received from you to convert it > into a > > proposal. Your suggestions in regard with this draft would definitely > help > > me to convert it into final proposal for submission. In addition, could > you > > please suggest the possible extensions those can be added to dump tool? > > > > > > Drive link to Draft Proposal: > > > > https://docs.google.com/document/d/1-jYwwDWsHQwMaxVsHFBrJ9EiCAev7lj > TDLS1xMwvK5w/edit > > The proposal looks a bit sparse when giving details about the actual > project. > I'd suggest to clarify at least the deliverables. I suggest for 1. add a > 1 c) > that specifies what should be working, for example > > lto-dump -l > > should dump a list of variables and functions contained in the IL > > lto-sump -s > > should dump detailed info about the symbol (using the symtab dump > infrastructure) > > lto-dump -f > > should dump the function body of the function with (using the gimple > dump infrastructure) > > the lto-dump tool should be verified to work on both WPA-time and > LTRANS-time > objects. > > Thus your 2) a) should be possible with 1) already. 2) would then contain > dumping of IPA summaries as major part apart from visualizing the > callgraph. > For visualizing the (full) callgraph you need to handle multiple LTO > IL input files. > Those two pieces should be enough for 2) unless usability issues spill ov= er > from 1). > > In the introduction I miss some general words about the LTO IL, like that > it > is non-self-describing bytecode which is documented only by the code > reading/writing it and thus hard to debug. It also misses to lay out the > overall structure of a LTO IL file (you are already going into detail with > IPA passes so this missing stands out). > > Richard. > > > > > Regards, > > > > Hrishikesh > > > > > > > > On Tue, Mar 6, 2018 at 8:59 PM, Jan Hubicka wrote: > >> > >> > On Tue, Mar 6, 2018 at 4:02 PM, Jan Hubicka wrote: > >> > >> On Tue, Mar 6, 2018 at 2:30 PM, Hrishikesh Kulkarni > >> > >> wrote: > >> > >> > Hi, > >> > >> > > >> > >> > Thank you Richard and Honza for the suggestions. If I understand > >> > >> > correctly, > >> > >> > the issue is that LTO file format keeps changing per compiler > >> > >> > versions, so > >> > >> > we need a more =E2=80=9Cstable=E2=80=9D representation and the = first step for > that > >> > >> > would be > >> > >> > to =E2=80=9Cstabilize=E2=80=9D representations for lto-cgraph a= nd symbol table ? > >> > >> > >> > >> Yes. Note the issue is that the current format is a 1:1 > >> > >> representation of > >> > >> the internal representation -- which means it is the internal > >> > >> representation > >> > >> that changes frequently across releases. I'm not sure how Honza > >> > >> wants > >> > >> to deal with those changes in the context of a "stable" IL format. > >> > >> Given > >> > >> we haven't been able to provide a stable API to plugins I think > it's > >> > >> much > >> > >> harder to provide a stable streaming format for all the IL > >> > >> details.... > >> > >> > >> > >> > Could you > >> > >> > please elaborate on what initial steps need to be taken in this > >> > >> > regard, and > >> > >> > if it=E2=80=99s feasible within GSoC timeframe ? > >> > >> > >> > >> I don't think it is feasible in the GSoC timeframe (nor do I think > >> > >> it's feasible > >> > >> at all ...) > >> > > > >> > > I skipped this, with GSoC timeframe I fully agree. With feasibili= ty > >> > > at all not so > >> > > much - LLVM documents its bitcode to reasonable extend > >> > > https://llvm.org/docs/BitCodeFormat.html > >> > > > >> > > Reason why i mentioned it is that I would like to use this as an > >> > > excuse to get > >> > > things incrementally cleaned up and it would be nice to keep it in > >> > > mind while > >> > > working on this. > >> > > >> > Ok. It's probably close enough to what I recommended doing with > respect > >> > to make the LTO bytecode "self-descriptive" -- thus start with making > >> > the > >> > structure documented and parseable without assigning semantics to > >> > every bit ;) I think that can be achieved top-down in a very > >> > incremental > >> > way if you get the bottom implemented first (the data-streamer part). > >> > >> OK :) > >> I did not mean to document every bit either, at least not for the fancy > >> parts. > >> It would be nice to have clenned up i.e. the section headers/footers so > >> they > >> do not depend on endianity and slowly cleanup similar nonsences at > higher > >> levels. So it may make sense to progress from both directions lower > >> hanging > >> fruits first. > >> > >> Honza > > > > >