Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754042AbcDVIyx (ORCPT ); Fri, 22 Apr 2016 04:54:53 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:16422 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753874AbcDVIyt (ORCPT ); Fri, 22 Apr 2016 04:54:49 -0400 Date: Fri, 22 Apr 2016 09:54:45 +0100 From: Paul Burton To: "Maciej W. Rozycki" CC: Ralf Baechle , Fengguang Wu , , , Philip Li Subject: Re: [kbuild-all] mipsel-linux-gnu-gcc: error: unrecognized command line option '-mcompact-branches=optimal' Message-ID: <20160422085445.GA14781@NP-P-BURTON> References: <201604201320.YHjfc2dZ%fengguang.wu@intel.com> <20160420133021.GG24051@linux-mips.org> <20160421045129.GB4038@wfg-t540p.sh.intel.com> <20160421203415.GK24051@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [10.100.200.114] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2196 Lines: 45 On Thu, Apr 21, 2016 at 10:10:51PM +0100, Maciej W. Rozycki wrote: > On Thu, 21 Apr 2016, Ralf Baechle wrote: > > > > I don't think it makes sense as the compiler won't support MIPSr6 code > > > anyway, so first it'll bail out on `-march=mips32r6', and if we go even > > > further and disable that too, then GAS will probably break somewhere on > > > inline asm and GCC will produce code which does not make sense otherwise. > > > > GCC 5.2.0 claims to support mips32r6 and mips64r6. It's just the option > > -mcompact-branches which seem to have been added later only. > > Ah, I see -- I didn't track the timeline of support for this compiler's > option and I took it from an earlier response that the compiler does not > support R6 at all. > > In that case however it looks to me like these `-mcompact-branches=' > options (all the three we support) need to be wrapped into `$(call > cc-option,...)'. An alternative that it could be argued better fits the principle of least surprise is to add an extra option to the Kconfig choice that simply leaves -mcompact-branches unspecified. I just submitted a patch to do so [1]. > They do not affect any functionality and they are an > optimisation choice only anyway (and therefore I wonder why they've been > placed in arch/mips/Kconfig.debug rather than arch/mips/Kconfig). They're in Kconfig.debug because debug is exactly what they've been useful for - given that compact branches are new to R6 it's been useful in debugging systems, both hardware & simulators, to sometimes not use them. It's also been useful to force their use attempting to work around the compiler bug that [2] works around differently (bug 2179 on DMZ bugzilla). On the other hand I can't think of a reason we'd want to specify compact branch policy that isn't for debug - I'd expect for performance optimisation we're more likely to rely upon the toolchain using a sensible policy if the kernel is built for a specific CPU (eg. perhaps -mcpu=p6600 prefers non-compact branches & -mcpu=m6250 prefers all compact branches, or similar). Thanks, Paul [1] https://patchwork.linux-mips.org/patch/13165/ [2] https://patchwork.linux-mips.org/patch/12556/