From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129553 invoked by alias); 9 Aug 2019 11:23:15 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 129545 invoked by uid 89); 9 Aug 2019 11:23:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-lj1-f176.google.com Received: from mail-lj1-f176.google.com (HELO mail-lj1-f176.google.com) (209.85.208.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Aug 2019 11:23:13 +0000 Received: by mail-lj1-f176.google.com with SMTP id v24so91922097ljg.13 for ; Fri, 09 Aug 2019 04:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WhpIUyq+cnbuYoP1nqQ5VY3s55x7iL7M1NWssFuiEus=; b=Onna0jHLjdH8JlomaLvYUkNl6q2qZUIB6mnxYLxhe/6TwrtzO8uIU3/ITtRdWucL2s r4KLeRRdr9cmQBSD9miuw7hBJzPbsn+odNejd+BLxBnC/zNFiENv1NYmiLdvAUEODHAK /JY11uZUCSpZ/4uKahG9cuQ/r9mzTauOOX74ENIh4UFQ+IN+jECpF/ahkvr5jtFs70Ty URwxT5w82ED8PRosjzuDWTGk8AA+Sp3Jk2ZEmiWJnQt7YVf8A+agegretrYSYpTHWk+U e2YQEFM1vtNTBw8gBQ5JWLf7kic5RWTGhV+4xWej2SJq2LdBcsmxgKEX+P1bKeQfvrem qdKQ== MIME-Version: 1.0 References: <433b51aaa31cb10d9336f3cb967384770c28bd92.camel@marvell.com> In-Reply-To: <433b51aaa31cb10d9336f3cb967384770c28bd92.camel@marvell.com> From: Richard Biener Date: Fri, 09 Aug 2019 12:13:00 -0000 Message-ID: Subject: Re: RFC: Help with updating LTO documentation To: Steve Ellcey Cc: "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00626.txt.bz2 On Wed, Aug 7, 2019 at 6:33 PM Steve Ellcey wrote: > > While trying to use the -flto and -fwhole-program flags I ran into problems > understanding what they do. I would like to update the documentation but I > still don't understand these flags enough to be able to describe their > behaviour. Here is the document section I would like to fix but don't > have enough information to do so. > > From lto.texi: > > | @subsection LTO modes of operation > | > | One of the main goals of the GCC link-time infrastructure was to allow > | effective compilation of large programs. For this reason GCC implements two > | link-time compilation modes. > | > | @enumerate > | @item @emph{LTO mode}, in which the whole program is read into the > | compiler at link-time and optimized in a similar way as if it > | were a single source-level compilation unit. > | > | @item @emph{WHOPR or partitioned mode}, designed to utilize multiple > | CPUs and/or a distributed compilation environment to quickly link > | large applications. WHOPR stands for WHOle Program optimizeR (not to > | be confused with the semantics of @option{-fwhole-program}). It > | partitions the aggregated callgraph from many different @code{.o} > | files and distributes the compilation of the sub-graphs to different > | CPUs. > > What flag(s) do I use (or not use) to enable @emph{LTO mode}? > I am guessing that if I use -flto but not -flto-partition on a > link, this is what I get. Is that correct? > > What flag(s) do I use to enable @emph{WHOPR or partitioned mode}? > I am guessing that this is -flto-partition? Do I also need -flto if I > am using -flto-partition? I don't see any description in lto.texi or in > common.opt of exactly what the various values for -flto-partition > (none, one, balanced, 1to1, max) do. Does such a description exist > anywhere? "LTO mode" is merely legacy and can be invoked with -flto -flto-partition=none while "WHOPR mode" is the default and is used with plain -flto. Both modes use a linker-plugin (if available) to enable "whole program" mode (aka auto-detection of -fwhole-program). Not using a linker-plugin is legacy as well. Richard. > Steve Ellcey > sellcey@marvell.com