On 13/09/16 13:43, Ralf Baechle wrote:
> On Mon, Sep 12, 2016 at 10:58:06AM +0100, Paul Burton wrote:
>
>> Fixing this by hiding the Kconfig entry behind another seems to be more
>> hassle than it's worth, as MIPSr6 & compact branches have been around
>> for a while now and if policy does need to be set for debug it can be
>> done easily enough with KCFLAGS. Therefore remove the compact branch
>> policy Kconfig entries & their handling in the Makefile.
>
> I've applied your patch - and given where we are wrt. to R6 I think this
> simply and bulletproof solution is certainly the right thing.
>
> But, have you considered probing for the option and only using it where
> it actually is available with something like:
>
> cflags-$(CONFIG_MIPS_COMPACT_BRANCHES_NEVER) += $(call cc-option,-mcompact-branches=never)
> cflags-$(CONFIG_MIPS_COMPACT_BRANCHES_OPTIMAL) += $(call cc-option,-mcompact-branches=optimal)
> cflags-$(CONFIG_MIPS_COMPACT_BRANCHES_ALWAYS) += $(call cc-option,-mcompact-branches=always)
>
> ?
Hi Ralf,
I believe that suggestion came up in discussion about an older patch,
but I think that might violate the principle of least surprise. ie. it
would mean you could set the policy to never in Kconfig, build a kernel
& it could contain compact branches.
> I'm also wondering how much we gain from -mcompact-branches?
>
> Ralf
Well, the default policy is "optimal" so we shouldn't gain much if
anything from tweaking it via Kconfig. Different CPUs/pipelines have
different gains, and the compiler should do something sensible for the
target CPU when the default optimal policy is set. This was always about
debugging, and KCFLAGS seems good enough for that especially since there
shouldn't be much to debug anymore.
Thanks,
Paul
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html