All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@imgtec.com>
To: Paul Burton <paul.burton@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 16:48:28 +0100	[thread overview]
Message-ID: <alpine.DEB.2.00.1604221425010.21846@tp.orcam.me.uk> (raw)
In-Reply-To: <20160422085445.GA14781@NP-P-BURTON>

On Fri, 22 Apr 2016, Paul Burton wrote:

> >  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].

 Hmm, good idea in principle, but given that -- as you say -- this is a 
debug option I have a further suggestion I'll reply to your patch 
submission with.

> > 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).

 Good point, it should indeed be the compiler making the right choice for 
the `-mtune=' setting selected with the default branch policy rather the 
user fiddling with `-mcompact-branches=' manually unless, as you say, for 
debugging.

 Thanks for the patience to educate me.

  Maciej

  reply	other threads:[~2016-04-22 15:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-20  5:44 mipsel-linux-gnu-gcc: error: unrecognized command line option '-mcompact-branches=optimal' 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
2016-04-22 15:48             ` Maciej W. Rozycki [this message]
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=alpine.DEB.2.00.1604221425010.21846@tp.orcam.me.uk \
    --to=macro@imgtec.com \
    --cc=fengguang.wu@intel.com \
    --cc=kbuild-all@01.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul.burton@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.