From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20838 invoked by alias); 25 Feb 2003 17:59:45 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 20822 invoked from network); 25 Feb 2003 17:59:45 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by 172.16.49.205 with SMTP; 25 Feb 2003 17:59:45 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.3/8.12.3) with ESMTP id h1PHxhTb013098 for ; Tue, 25 Feb 2003 09:59:43 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Feb 2003 09:59:40 -0800 Received: from apple.com (isolde.apple.com [17.201.24.249]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id h1PHxgf00042; Tue, 25 Feb 2003 09:59:42 -0800 (PST) Date: Tue, 25 Feb 2003 18:01:00 -0000 Subject: Re: Inlining (was: GCC 3.3 release criteria) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: gcc@gcc.gnu.org To: Tolga Dalman From: Matt Austern In-Reply-To: <20030225042011.1864b3ed.ates100@web.de> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg01756.txt.bz2 On Monday, February 24, 2003, at 07:20 PM, Tolga Dalman wrote: >> We definitely don't want -fobey-inline to be the default: usually it's >> better for the compiler to treat the inline keyword as a hint, and to >> use its own heuristics to decide when to accept the hint. But there >> are >> cases, as you've found, when a flag like this is useful. >> > > this confuses me a bit. i always thought, that the "inline" keyword > would > in any case force inlining, except for the -fno-inline flag activated. > IMHO, the compiler should always obey user inlining, because the > compiler > should trust the programmer when he uses an optional feature (such as > inline). > for me, the question evolves: what does happen in -Os optimization? i > suppose, > there isn't done any inline at all, not even explicitely "inline" > marked > functions, no? Some programmers have the expectation that the compiler will always inline everything that's marked inline. Other programmers very definitely do not expect that, and write code where 'inline' is treated merely as a hint to the compiler: marking a function 'inline' means you're telling the compiler that you won't mind if it chooses to inline the function. (Inline-as-hint is what the C++ Standard says, for what it's worth. I don't know the C99 standard as well.) Empirically, treating 'inline' as a directive rather than a hint will make a lot of programs much worse. This isn't conjecture. We did the measurement at Apple. -fobey-inline is occasionally useful, but making it the default would be disastrous. In the end I expect that more and more compilers will choose to ignore the 'inline' keyword entirely. They'll treat it the same way as 'register', and for the same reason: a sufficiently clever optimizer has more information than the programmer does, and can do a better job of knowing which functions should be inlined. Some optimizers are already good enough so that's true. Our optimizer isn't (yet), but that's where we eventually want to be. --Matt