Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753878AbbDUK45 (ORCPT ); Tue, 21 Apr 2015 06:56:57 -0400 Received: from mail-lb0-f175.google.com ([209.85.217.175]:32787 "EHLO mail-lb0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751734AbbDUK4z (ORCPT ); Tue, 21 Apr 2015 06:56:55 -0400 MIME-Version: 1.0 In-Reply-To: <20150421074212.GA25081@gmail.com> References: <1429565231-4609-1-git-send-email-hagen@jauu.net> <20150420215645.GC10191@pd.tnic> <20150421074212.GA25081@gmail.com> Date: Tue, 21 Apr 2015 12:56:53 +0200 Message-ID: Subject: Re: [PATCH RFC] x86: enforce inlining for atomics From: Hagen Paul Pfeifer To: Ingo Molnar Cc: Linus Torvalds , Borislav Petkov , "linux-kernel@vger.kernel.org" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , Andrew Morton Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1610 Lines: 41 On 21 April 2015 at 09:42, Ingo Molnar wrote: Hey Ingo, Peter, Boris, the environment is Debian with gcc version 4.9.2. I tried to reproduce the results under Ubuntu 14.04 but their version (4.8.2!) seems fine: at max one duplicate for each atomic_* function. > So the thing is that allyesconfig turns on -Os: > > CONFIG_CC_OPTIMIZE_FOR_SIZE=y > > which is known to make bad decisions in other areas as well ... I can recompile with "CONFIG_CC_OPTIMIZE_FOR_SIZE=n" and check the results again!? > If -Os does such bad inlining decisions (and the inlining examples you > cited are horrible!) then I guess a lot of the other 'inline' > functions are handled by it badly as well. Assumption is correct - I see duplicates all over the place. > I'm not sure we should start fighting the compiler: if a compiler does > not take 'inline' seriously then the solution is to use another > compiler, or at least to use different compiler flags. > > If inlining decisions are bad even with saner compiler options then we > can use __always_inline, and we actually do that for locking > primitives and some other low level primitives: which are typically > larger than atomics, so even reasonable compilers might uninline them. Probably we should check this on a wider gcc front! If the behavior is an exception, or is this common behavior? Hagen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/