[Buildroot] [PATCH v2] xtensa: add config option to enable longcalls option

[Buildroot] [PATCH v2] xtensa: add config option to enable longcalls option

[Chris Zankel]

The longcalls option allows calls across a greater range of addresses.

This option should be used when call targets can potentially be
out of range. It may degrade both code size and performance, but
the linker can generally optimize away the unnecessary overhead
when a call ends up within range.

This option is enabled by default.

Signed-off-by: Chris Zankel <chris@zankel.net>
---
 arch/Config.in.xtensa |   17 +++++++++++++++++
 package/Makefile.in   |    6 ++++++
 2 files changed, 23 insertions(+)

diff --git a/arch/Config.in.xtensa b/arch/Config.in.xtensa
index 60c03f5..a979108 100644
--- a/arch/Config.in.xtensa
+++ b/arch/Config.in.xtensa
@@ -35,3 +35,20 @@ config BR2_XTENSA_OVERLAY_DIR
 
 config BR2_ARCH
 	default "xtensa"	if BR2_xtensa
+
+menu "Target build options"
+
+config BR2_XTENSA_LONGCALLS
+	bool "Enable longcalls option"
+	default y
+	help
+	  Enable or disable transformation of call instructions to allow
+	  calls across a greater range of addresses.
+	  This option should be used when call targets can potentially be
+	  out of range. It may degrade both code size and performance, but
+	  the linker can generally optimize away the unnecessary overhead
+	  when a call ends up within range. 
+
+	  Should be enabled by default.
+
+endmenu
diff --git a/package/Makefile.in b/package/Makefile.in
index 9fdc745..b52d5e0 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -56,6 +56,12 @@ TARGET_ABI+=-mabi=spe -mfloat-gprs=double -Wa,-me500mc
 endif
 endif
 
+# Xtensa: The 'longcalls' option is required for large binary packages.
+# Use a global option for all packages for now.
+ifeq ($(BR2_XTENSA_LONGCALLS),y)
+TARGET_CFLAGS += -mlongcalls
+endif
+
 STAGING_DIR=$(HOST_DIR)/usr/$(GNU_TARGET_NAME)/sysroot
 
 TARGET_OPTIMIZATION:=$(call qstrip,$(BR2_TARGET_OPTIMIZATION))
-- 
1.7.9.5

[Buildroot] [PATCH v2] xtensa: add config option to enable longcalls option

[Thomas Petazzoni]

Dear Chris Zankel,

On Mon, 3 Dec 2012 00:58:46 -0800, Chris Zankel wrote:
> The longcalls option allows calls across a greater range of addresses.
> 
> This option should be used when call targets can potentially be
> out of range. It may degrade both code size and performance, but
> the linker can generally optimize away the unnecessary overhead
> when a call ends up within range.
> 
> This option is enabled by default.
> 
> Signed-off-by: Chris Zankel <chris@zankel.net>
> ---
>  arch/Config.in.xtensa |   17 +++++++++++++++++
>  package/Makefile.in   |    6 ++++++
>  2 files changed, 23 insertions(+)
> 
> diff --git a/arch/Config.in.xtensa b/arch/Config.in.xtensa
> index 60c03f5..a979108 100644
> --- a/arch/Config.in.xtensa
> +++ b/arch/Config.in.xtensa
> @@ -35,3 +35,20 @@ config BR2_XTENSA_OVERLAY_DIR
>  
>  config BR2_ARCH
>  	default "xtensa"	if BR2_xtensa
> +
> +menu "Target build options"
> +
> +config BR2_XTENSA_LONGCALLS
> +	bool "Enable longcalls option"
> +	default y
> +	help
> +	  Enable or disable transformation of call instructions to allow
> +	  calls across a greater range of addresses.
> +	  This option should be used when call targets can potentially be
> +	  out of range. It may degrade both code size and performance, but
> +	  the linker can generally optimize away the unnecessary overhead
> +	  when a call ends up within range. 
> +
> +	  Should be enabled by default.
> +
> +endmenu

Do we really want that as a configurable option? Isn't it possible
instead to always generate longcalls, or to fix this on a per-package
basis, when needed?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH v2] xtensa: add config option to enable longcalls option

[czankel]

On 12/3/12 5:09 AM, Thomas Petazzoni wrote:
> Dear Chris Zankel,
>
> On Mon, 3 Dec 2012 00:58:46 -0800, Chris Zankel wrote:
>> The longcalls option allows calls across a greater range of addresses.
>>
>> This option should be used when call targets can potentially be
>> out of range. It may degrade both code size and performance, but
>> the linker can generally optimize away the unnecessary overhead
>> when a call ends up within range.
>>
> Do we really want that as a configurable option? Isn't it possible
> instead to always generate longcalls, or to fix this on a per-package
> basis, when needed?
The actual distance between call and destination is probably very 
dependent on compiler versions and compile options, etc., so might be 
hard to figure out what packages are affected. We might end up with a 
lot of packages with special Xtensa  'treatments'. Probably better to 
just have it always there.

It should actually be fine to always compile with the longcalls option, 
but I didn't just want to change it without having the option to keep 
the old behavior, hence the option.

Thanks,
-Chris

[Buildroot] [PATCH v2] xtensa: add config option to enable longcalls option

[Thomas Petazzoni]

On Tue, 04 Dec 2012 00:36:32 -0800, czankel wrote:

> > Do we really want that as a configurable option? Isn't it possible
> > instead to always generate longcalls, or to fix this on a per-package
> > basis, when needed?
> The actual distance between call and destination is probably very 
> dependent on compiler versions and compile options, etc., so might be 
> hard to figure out what packages are affected. We might end up with a 
> lot of packages with special Xtensa  'treatments'. Probably better to 
> just have it always there.

Hum, right.

> It should actually be fine to always compile with the longcalls option, 
> but I didn't just want to change it without having the option to keep 
> the old behavior, hence the option.

I'd prefer to have it always enabled, I'd say. We try to not add
gazillions of very detailed architecture-specific options that are
hard to understand. Hardcore users will know how/where to remove this
option is they need, or they can even override it by passing a
-mno-longcalls option in BR2_TARGET_OPTIMIZATION.

What do you think?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH v2] xtensa: add config option to enable longcalls option

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 >> It should actually be fine to always compile with the longcalls option, 
 >> but I didn't just want to change it without having the option to keep 
 >> the old behavior, hence the option.

 Thomas> I'd prefer to have it always enabled, I'd say. We try to not add
 Thomas> gazillions of very detailed architecture-specific options that are
 Thomas> hard to understand. Hardcore users will know how/where to remove this
 Thomas> option is they need, or they can even override it by passing a
 Thomas> -mno-longcalls option in BR2_TARGET_OPTIMIZATION.

 Thomas> What do you think?

I agree. Lets use the safe option by default.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v2] xtensa: add config option to enable longcalls option

[Chris Zankel]

Hi,

On 12/04/2012 12:13 PM, Peter Korsgaard wrote:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Hi,
>
>  >> It should actually be fine to always compile with the longcalls option, 
>  >> but I didn't just want to change it without having the option to keep 
>  >> the old behavior, hence the option.
>
>  Thomas> I'd prefer to have it always enabled, I'd say. We try to not add
>  Thomas> gazillions of very detailed architecture-specific options that are
>  Thomas> hard to understand. Hardcore users will know how/where to remove this
>  Thomas> option is they need, or they can even override it by passing a
>  Thomas> -mno-longcalls option in BR2_TARGET_OPTIMIZATION.
>
>  Thomas> What do you think?
>
> I agree. Lets use the safe option by default.
>
Not sure what you mean with the 'safe option'? I'm also not sure what
the preference for options is when you pass both, the -mlongcalls and
-mno-longcalls option at the same time?

Anyway, I'm fine with whatever solution you come up with, as long as it
makes it into the tree :-)

Thanks,
-Chris

[Buildroot] [PATCH v2] xtensa: add config option to enable longcalls option

[Thomas Petazzoni]

Dear Chris Zankel,

On Tue, 04 Dec 2012 12:40:51 -0800, Chris Zankel wrote:

> > I agree. Lets use the safe option by default.
> >
> Not sure what you mean with the 'safe option'? I'm also not sure what

I guess Peter means enabling "-mlongcalls" all the time. My
understanding (and I think Peter did understand it the same way) is
that if you build with -mlongcalls, then all binaries will work, both
small and large binaries, even though there is a small size
and performance cost.

So, what we propose is to simply make -mlongcalls part of the CFLAGS
unconditionally in the Buildroot Xtensa support.

> the preference for options is when you pass both, the -mlongcalls and
> -mno-longcalls option at the same time?

The last one takes precedence, I think.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH v2] xtensa: add config option to enable longcalls option

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> Dear Chris Zankel,
 Thomas> On Tue, 04 Dec 2012 12:40:51 -0800, Chris Zankel wrote:

 >> > I agree. Lets use the safe option by default.
 >> >
 >> Not sure what you mean with the 'safe option'? I'm also not sure what

 Thomas> I guess Peter means enabling "-mlongcalls" all the time. My
 Thomas> understanding (and I think Peter did understand it the same way) is
 Thomas> that if you build with -mlongcalls, then all binaries will work, both
 Thomas> small and large binaries, even though there is a small size
 Thomas> and performance cost.

 Thomas> So, what we propose is to simply make -mlongcalls part of the CFLAGS
 Thomas> unconditionally in the Buildroot Xtensa support.

Indeed.

-- 
Bye, Peter Korsgaard