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
next prev parent 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.