mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Burton <paul.burton@imgtec.com>
To: "Maciej W. Rozycki" <macro@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Fengguang Wu <fengguang.wu@intel.com>, <kbuild-all@01.org>,
	<linux-kernel@vger.kernel.org>, Philip Li <philip.li@intel.com>
Subject: Re: [kbuild-all] mipsel-linux-gnu-gcc: error: unrecognized command line option '-mcompact-branches=optimal'
Date: Fri, 22 Apr 2016 09:54:45 +0100	[thread overview]
Message-ID: <20160422085445.GA14781@NP-P-BURTON> (raw)
In-Reply-To: <alpine.DEB.2.00.1604212159440.21846@tp.orcam.me.uk>

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/

  reply	other threads:[~2016-04-22  8:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-20  5:44 kbuild test robot
2016-04-20 13:30 ` Ralf Baechle
2016-04-21  4:51   ` [kbuild-all] " Fengguang Wu
2016-04-21 19:55     ` Maciej W. Rozycki
2016-04-21 20:34       ` Ralf Baechle
2016-04-21 21:10         ` Maciej W. Rozycki
2016-04-22  8:54           ` Paul Burton [this message]
2016-04-22 15:48             ` Maciej W. Rozycki
2016-04-21 20:31     ` Ralf Baechle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160422085445.GA14781@NP-P-BURTON \
    --to=paul.burton@imgtec.com \
    --cc=fengguang.wu@intel.com \
    --cc=kbuild-all@01.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@imgtec.com \
    --cc=philip.li@intel.com \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome