From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964853AbdKPQRn (ORCPT ); Thu, 16 Nov 2017 11:17:43 -0500 Received: from mail-it0-f65.google.com ([209.85.214.65]:45711 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935084AbdKPQRg (ORCPT ); Thu, 16 Nov 2017 11:17:36 -0500 X-Google-Smtp-Source: AGs4zMZGN/zZNm6bmuZlagGHEaXoUa+BFJPWn49T9cjduzh6jjlbKs8XlzG+6ILv4nkOB/VJSBPLCg== Date: Thu, 16 Nov 2017 08:17:31 -0800 From: Sami Tolvanen To: Will Deacon Cc: Alex Matveev , Andi Kleen , Ard Biesheuvel , Greg Hackmann , Kees Cook , linux-arm-kernel@lists.infradead.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, Mark Rutland , Masahiro Yamada , Maxim Kuvyrkov , Michal Marek , Nick Desaulniers , Yury Norov , Matthias Kaehlcke , peterz@infradead.org, paulmck@linux.vnet.ibm.com Subject: Re: [PATCH v2 18/18] arm64: select ARCH_SUPPORTS_LTO_CLANG Message-ID: <20171116161731.GA94341@samitolvanen.mtv.corp.google.com> References: <20171115213428.22559-1-samitolvanen@google.com> <20171115213428.22559-19-samitolvanen@google.com> <20171116115810.GH9361@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171116115810.GH9361@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 16, 2017 at 11:58:11AM +0000, Will Deacon wrote: > I'll be honest with you: I'm absolutely terrified about enabling this. That's understandable, I wouldn't want to enable this by default quite yet either. This patch doesn't enable LTO for arm64, just makes it possible to enable the feature. I'm perfectly fine with marking CONFIG_LTO_CLANG experimental if it makes people more comfortable. > How much testing has this seen? I've been running clang LTO kernels for a few months on a Pixel 2 device without any issues. This is on a 4.4 kernel though. > Right now, the C standard isn't on our side here and we're relying on > the compiler not doing this kind of thing. Can we continue to rely on > that in the face of LTO? I'll have to check with our LLVM experts, but I have not run into these issues with current compiler versions. Looking at Andi's old patches, looks like gcc might be more aggressive in reordering things with LTO than clang. Sami