From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17585 invoked by alias); 13 Oct 2009 01:19:01 -0000 Received: (qmail 17573 invoked by uid 22791); 13 Oct 2009 01:19:01 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI X-Spam-Check-By: sourceware.org Received: from cantor.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Oct 2009 01:18:55 +0000 Received: from relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 6FE9D90975; Tue, 13 Oct 2009 03:18:53 +0200 (CEST) Date: Tue, 13 Oct 2009 01:29:00 -0000 From: Michael Matz To: Jeff Law Cc: Richard Guenther , Jan Hubicka , Toon Moene , Jan Hubicka , gcc mailing list Subject: Re: LTO and the inlining of functions only called once. In-Reply-To: <4AD3AB29.7070204@redhat.com> Message-ID: References: <4AD0681E.5040200@moene.org> <84fc9c000910100400v5f1f4f35n5cd5c37c38c1420d@mail.gmail.com> <20091010123125.GO9046@atrey.karlin.mff.cuni.cz> <20091010151737.GA18743@caradoc.them.org> <4AD0B52D.1010202@redhat.com> <84fc9c000910100940u26cb368cj27e935802427f4d3@mail.gmail.com> <4AD3AB29.7070204@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes 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/msg00265.txt.bz2 Hi, On Mon, 12 Oct 2009, Jeff Law wrote: > To put things in perspective, the particular person I spoke with spent > many days trying to understand why a particular function wasn't being > inlined -- presumably they'd see "grep logfile" as a > huge improvement over the days and days of twiddling sources, tuning > options, etc, even if that presented them with a large amount of data to > analyze. If we would listen to such requests by providing the requested information, nothing stops users from asking to have something like that also for other transformations. Like "I've spent days and days with analyzing why this loop isn't unrolled, I'd like to have -Winfo-unroll to tell me exactly when a loop is unrolled, and when it isn't for which reason". Make "loop is unrolled" be $TRANSFORMATION and it becomes silly. I don't think this is reductio ad absurdum. We have dump files for exactly such information. Maybe the latter could be molded (via an new flag) into something less detailed than now, but still containing the larger decisions. Ciao, Michael.