Path: csiph.com!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Bo Persson Newsgroups: comp.lang.c++ Subject: Re: I was wrong about gcc's inlining behavior Date: Fri, 21 Oct 2022 16:41:44 +0200 Lines: 23 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net NQxQn3uP6c7c/LTJv5lUbwNqL3mh8cbums0ywKy7mQaBgmFuUu Cancel-Lock: sha1:Al8L9eAibU1LZKkq/RkYC9hxSgo= User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3 Content-Language: sv In-Reply-To: Xref: csiph.com comp.lang.c++:87116 On 2022-10-21 at 13:44, Juha Nieminen wrote: > (I don't know if this applies to other compilers like clang. Could be.) > > For the longest time I thought that if gcc sees a function implementation > at the place where the function is being called, then it doesn't matter > if the keyword 'inline' appears before that function implementation or > not. I thought that gcc just ignores that keyword when making inlining > decisions. (After all, why wouldn't it?) > > Just now, however, I got a concrete counter-example to this. > > > So it appears that I have been wrong: When it comes to functions visible > at the global scope, the 'inline' keyword can make a huge difference, > even when the implementations are seen by the compiler at the call > places. > It probably doesn't make a huge difference in general, but if your function is 'close' to getting inlined, an actual 'inline' keyword might add a few points to the heuristics, and tip it over the decision point.