From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13116 invoked by alias); 10 Oct 2009 17:16:41 -0000 Received: (qmail 13107 invoked by uid 22791); 10 Oct 2009 17:16:40 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from mx20.gnu.org (HELO mx20.gnu.org) (199.232.41.8) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 10 Oct 2009 17:16:35 +0000 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MwfYX-0000MY-FK for gcc@gcc.gnu.org; Sat, 10 Oct 2009 13:16:33 -0400 Received: (qmail 15732 invoked from network); 10 Oct 2009 17:16:31 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Oct 2009 17:16:31 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.69) (envelope-from ) id 1MwfYT-0001cn-KW; Sat, 10 Oct 2009 17:16:29 +0000 Date: Sat, 10 Oct 2009 17:26:00 -0000 From: "Joseph S. Myers" To: Diego Novillo cc: Jan Hubicka , Richard Guenther , Toon Moene , Jan Hubicka , gcc mailing list Subject: Re: LTO and the inlining of functions only called once. In-Reply-To: Message-ID: References: <4AD0681E.5040200@moene.org> <84fc9c000910100400v5f1f4f35n5cd5c37c38c1420d@mail.gmail.com> <20091010123125.GO9046@atrey.karlin.mff.cuni.cz> <20091010151737.GA18743@caradoc.them.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1152306461-1835855866-1255194989=:5233" X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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 X-SW-Source: 2009-10/txt/msg00217.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1152306461-1835855866-1255194989=:5233 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-length: 1701 On Sat, 10 Oct 2009, Diego Novillo wrote: > On Sat, Oct 10, 2009 at 11:17, Daniel Jacobowitz wrote: > > On Sat, Oct 10, 2009 at 02:31:25PM +0200, Jan Hubicka wrote: > >> My solution would be probably to pass -fdump-ipa-inline parameter to l= to > >> compilation and read the log. =C2=A0It lists the inlining decisions an= d if > >> something is not inlined, you get dump of reason why. > > > > GCC's dumps are really aimed at compiler developers. =C2=A0I think we w= ould > > benefit from more "what is the compiler doing to my code" options > > (producing "note:"); things like which functions were inlined, which > > loops unrolled. =C2=A0We do already have this for vectorization. >=20 > Agreed. We've had some discussions on this and there's been some > efforts started (http://gcc.gnu.org/wiki/Pass%20Activity%20Log), but > nothing concrete so far. >=20 > We should evolve a generic reporting facility for passes to produce > human readable logs on what they did, what they couldn't do, reasons, > etc. We should also keep in mind that such logs aimed at users should support=20 i18n - unlike the existing dumps for compiler developers, which are quite=20 properly English only, and most calls to internal_error which should only=20 appear if there is a compiler bug and are also only meant to be useful for= =20 compiler developers (so represent useless work for translators at present=20 - though it does seem possible some internal_error calls could actually=20 appear with invalid input rather than compiler bugs and so should be=20 normal errors). If you're generating "note:" via inform(), the i18n support is automatic. --=20 Joseph S. Myers joseph@codesourcery.com= ---1152306461-1835855866-1255194989=:5233--