| Message ID | 50bc6a34.45e8440a.493d.4091@mx.google.com |
|---|---|
| State | Changes Requested |
| Headers | show |
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
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
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" == 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.
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
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" == 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.
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))
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(+)