Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3237181imu; Mon, 17 Dec 2018 16:09:07 -0800 (PST) X-Google-Smtp-Source: AFSGD/Vqk4UkHLRHJ/j3fUKcjAZ2AHZgCSzdtVLh+DvVq/Am4jE1VWInvn6E3Wjn9BalAS+SWSzY X-Received: by 2002:a17:902:70c6:: with SMTP id l6mr14859182plt.30.1545091747501; Mon, 17 Dec 2018 16:09:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545091747; cv=none; d=google.com; s=arc-20160816; b=td0KaRjELLa+OWYw1u/GUNaFLiW5VvA5QGrFbae9F2RH5d+hBFaBffe3W2q7mZu763 w7mukkPbrPx5VWUZwWtTt/92pyIIVq1rLzFOZjVT+xcu63RbNDDx6FZlBU5C1nQHmTpJ m7ES0x4s9LEKo5g9BsrJFqs3j6IGHT+LrwyyUdrdpvAGFu/DleDhDE4zTJSzqUcg/wvK ZEMUmG2AACyXbLlfkTUkzBHgdNdfXTNZXBQoJ47l7MZoesl+rBK5ni2zpynwzOI/UGsI JZfm0jnw9YX3M7d7PgJ7jK7RmrcyzXDRFZJcthCbYEEi7ebo1T3o+Jq1E2dwRhYYGIGV H6sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=1M3xXjlB1BSg7xjUCoFTiGnetJSSnjgeX9kflOI8stM=; b=oF8t0cP5JVCeOQM2G55yeborLwvZ+ZiXfFilJy0cf19Q+XmeNpl599UojB/O9CZVFv DGgeTa0SoNEAhscpb4d5dQs+FGegRTQLugXqD7Hx9l0pPJnnBi4XskaalWQairFPRrAZ V5aH23+ywpnmcD5JOzOG4J06+0XBIugoHZZPNR79r9gjSxJ2VGpi+TQeQzXb61CUDAR+ 8PBzIIxIBWIdufZjeZ3WO5dgt5WnKdLUCipnWA0kEuE1jPkGmV8lzDCmA0dw+kMlke73 xGDuyEeFCh9VDPQ0v3Wd08Bjkezo3NYxHe4jpd0e2lXDfJztSW4oW45l6J/mfcYcK1rd kZLQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d34si9345625pla.80.2018.12.17.16.08.51; Mon, 17 Dec 2018 16:09:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726340AbeLRAIB (ORCPT + 99 others); Mon, 17 Dec 2018 19:08:01 -0500 Received: from mga06.intel.com ([134.134.136.31]:30032 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726271AbeLRAIB (ORCPT ); Mon, 17 Dec 2018 19:08:01 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2018 16:08:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,366,1539673200"; d="scan'208";a="99489609" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.137]) by orsmga007.jf.intel.com with ESMTP; 17 Dec 2018 16:08:00 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id 9A836300B49; Mon, 17 Dec 2018 16:08:00 -0800 (PST) Date: Mon, 17 Dec 2018 16:08:00 -0800 From: Andi Kleen To: Peter Zijlstra Cc: Arnd Bergmann , Nicolas Pitre , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Paul McKenney , Will Deacon , Ingo Molnar , Thomas Gleixner Subject: Re: [PATCH 0/7] ARM: hacks for link-time optimization Message-ID: <20181218000800.GB25620@tassilo.jf.intel.com> References: <20180220215954.4092811-1-arnd@arndb.de> <20181217225020.GA16520@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181217225020.GA16520@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 17, 2018 at 11:50:20PM +0100, Peter Zijlstra wrote: > On Tue, Feb 20, 2018 at 10:59:47PM +0100, Arnd Bergmann wrote: > > Hi Nico, all, > > > > I was playing with ARM link-time optimization handling earlier this > > month, and eventually got it to build cleanly with randconfig kernels, > > but ended up with a lot of ugly hacks to actually pull it off. > > How are we dealing with the fact that LTO can break RCU in very subtle > and scary ways? > > Do we have a compiler guy on board that has given us a compiler switch > that kills that optimization (and thereby guarantees that behaviour for > future compilers etc..) ? Can you actually define what optimization you are worred about? If there are optimizations that cause problems they likely happen even without LTO inside files. The only difference with LTO is that it does them between files too. -Andi