From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936812AbdKPURP (ORCPT ); Thu, 16 Nov 2017 15:17:15 -0500 Received: from mail-io0-f196.google.com ([209.85.223.196]:39958 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932144AbdKPURJ (ORCPT ); Thu, 16 Nov 2017 15:17:09 -0500 X-Google-Smtp-Source: AGs4zMb34Hhixm/nr5V+mBH2zaRQj5LcU+5HK4dt+/VSH55Jw/QVIe/8x5nz5/TfA69JhKLoA7jOJQ== Date: Thu, 16 Nov 2017 12:17:01 -0800 From: Sami Tolvanen To: "Paul E. McKenney" Cc: Will Deacon , Nick Desaulniers , Peter Zijlstra , Alex Matveev , Andi Kleen , Ard Biesheuvel , Greg Hackmann , Kees Cook , linux-arm-kernel@lists.infradead.org, Linux Kbuild mailing list , LKML , Mark Rutland , Masahiro Yamada , Maxim Kuvyrkov , Michal Marek , Yury Norov , Matthias Kaehlcke , Alexander Potapenko , Stephen Hines , Pirama Arumuga Nainar , Manoj Gupta Subject: Re: [PATCH v2 18/18] arm64: select ARCH_SUPPORTS_LTO_CLANG Message-ID: <20171116201701.GA143965@samitolvanen.mtv.corp.google.com> References: <20171116163054.kcsdsomr7u2mqql2@hirez.programming.kicks-ass.net> <20171116165922.llrojrvomuihabrt@hirez.programming.kicks-ass.net> <20171116173417.nqsh5dpu65uj7b5s@hirez.programming.kicks-ass.net> <20171116174830.GX3624@linux.vnet.ibm.com> <20171116183950.GA3624@linux.vnet.ibm.com> <20171116184508.GC21898@arm.com> <20171116191307.GC3624@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171116191307.GC3624@linux.vnet.ibm.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:13:07AM -0800, Paul E. McKenney wrote: > Ah, if "this patch set" meant "adding LTO", I stand corrected and I > apologize for my confusion. Again, I'm not proposing for LTO to be enabled by default. These patches just make it possible to enable it. Are you saying the possibility that a future compiler update breaks something is a blocker even for experimental features? > I agree that we need LTO/PGO to be housebroken from an LKMM viewpoint > before it is enabled. Can you elaborate what's needed from clang before this can move forward? For example, if you have specific test cases in mind, we can always work on including them in the LLVM test suite. Sami From mboxrd@z Thu Jan 1 00:00:00 1970 From: samitolvanen@google.com (Sami Tolvanen) Date: Thu, 16 Nov 2017 12:17:01 -0800 Subject: [PATCH v2 18/18] arm64: select ARCH_SUPPORTS_LTO_CLANG In-Reply-To: <20171116191307.GC3624@linux.vnet.ibm.com> References: <20171116163054.kcsdsomr7u2mqql2@hirez.programming.kicks-ass.net> <20171116165922.llrojrvomuihabrt@hirez.programming.kicks-ass.net> <20171116173417.nqsh5dpu65uj7b5s@hirez.programming.kicks-ass.net> <20171116174830.GX3624@linux.vnet.ibm.com> <20171116183950.GA3624@linux.vnet.ibm.com> <20171116184508.GC21898@arm.com> <20171116191307.GC3624@linux.vnet.ibm.com> Message-ID: <20171116201701.GA143965@samitolvanen.mtv.corp.google.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Nov 16, 2017 at 11:13:07AM -0800, Paul E. McKenney wrote: > Ah, if "this patch set" meant "adding LTO", I stand corrected and I > apologize for my confusion. Again, I'm not proposing for LTO to be enabled by default. These patches just make it possible to enable it. Are you saying the possibility that a future compiler update breaks something is a blocker even for experimental features? > I agree that we need LTO/PGO to be housebroken from an LKMM viewpoint > before it is enabled. Can you elaborate what's needed from clang before this can move forward? For example, if you have specific test cases in mind, we can always work on including them in the LLVM test suite. Sami