On Tue, 2013-02-19 at 20:31 -0600, Kim Phillips wrote:
>
> > > imx_v6_v7_defconfig:7672373 7667089 -5284
> > > lart_defconfig: 2941150 2941054 -96
> > > mxs_defconfig: 11091983110956793696
> >
> > The savings are good, with some imp
On Thu, 21 Feb 2013, Kim Phillips wrote:
> Here's the asm version I'm working on now, based on compiler
> output of the C version. Haven't tested beyond defconfig builds,
> which pass ok.
>
> Is there anything I have to do for thumb mode? If so, how to test?
You just need to pick a config that
On Thu, 21 Feb 2013 11:40:54 -0500
Nicolas Pitre wrote:
> On Thu, 21 Feb 2013, Kim Phillips wrote:
>
> > On Wed, 20 Feb 2013 23:29:58 -0500
> > Nicolas Pitre wrote:
> >
> > > On Wed, 20 Feb 2013, Kim Phillips wrote:
> > >
> > > > On Wed, 20 Feb 2013 10:43:18 -0500
> > > > Nicolas Pitre wrote
On Thu, 21 Feb 2013, Woodhouse, David wrote:
> On Wed, 2013-02-20 at 23:29 -0500, Nicolas Pitre wrote:
> > > > On Wed, 20 Feb 2013, Woodhouse, David wrote:
> > > > > For today's compilers, unless the wind changes.
> > …
> > Crap. OK, assembly code is the way to go then.
>
> How quickly the win
On Thu, 21 Feb 2013, Kim Phillips wrote:
> On Wed, 20 Feb 2013 23:29:58 -0500
> Nicolas Pitre wrote:
>
> > On Wed, 20 Feb 2013, Kim Phillips wrote:
> >
> > > On Wed, 20 Feb 2013 10:43:18 -0500
> > > Nicolas Pitre wrote:
> > >
> > > > On Wed, 20 Feb 2013, Woodhouse, David wrote:
> > > > > On W
On Wed, 2013-02-20 at 23:29 -0500, Nicolas Pitre wrote:
> > > On Wed, 20 Feb 2013, Woodhouse, David wrote:
> > > > For today's compilers, unless the wind changes.
> …
> Crap. OK, assembly code is the way to go then.
How quickly the wind changes, these days. I blame global warming. :)
--
On Wed, 20 Feb 2013 23:29:58 -0500
Nicolas Pitre wrote:
> On Wed, 20 Feb 2013, Kim Phillips wrote:
>
> > On Wed, 20 Feb 2013 10:43:18 -0500
> > Nicolas Pitre wrote:
> >
> > > On Wed, 20 Feb 2013, Woodhouse, David wrote:
> > > > On Wed, 2013-02-20 at 09:06 -0500, Nicolas Pitre wrote:
> > > > >
On Wed, 20 Feb 2013, Kim Phillips wrote:
> On Wed, 20 Feb 2013 10:43:18 -0500
> Nicolas Pitre wrote:
>
> > On Wed, 20 Feb 2013, Woodhouse, David wrote:
> > > On Wed, 2013-02-20 at 09:06 -0500, Nicolas Pitre wrote:
> > > > ... in which case there is no harm shipping a .c file and trivially
> > >
On Wed, 20 Feb 2013 10:43:18 -0500
Nicolas Pitre wrote:
> On Wed, 20 Feb 2013, Woodhouse, David wrote:
> > On Wed, 2013-02-20 at 09:06 -0500, Nicolas Pitre wrote:
> > > ... in which case there is no harm shipping a .c file and trivially
> > > enforcing -O2, the rest being equal.
> >
> > For tod
On Wed, 20 Feb 2013, Woodhouse, David wrote:
> On Wed, 2013-02-20 at 09:06 -0500, Nicolas Pitre wrote:
> > On Wed, 20 Feb 2013, Woodhouse, David wrote:
> >
> > > On Wed, 2013-02-20 at 08:36 -0500, Nicolas Pitre wrote:
> > > > You'll have the same issue wrt the above whether or not the source
> >
On Wed, 2013-02-20 at 09:06 -0500, Nicolas Pitre wrote:
> On Wed, 20 Feb 2013, Woodhouse, David wrote:
>
> > On Wed, 2013-02-20 at 08:36 -0500, Nicolas Pitre wrote:
> > > You'll have the same issue wrt the above whether or not the source
> > > file is C or assembly.
> >
> > Hm, true. I was thinki
On Wed, 20 Feb 2013, Woodhouse, David wrote:
> On Wed, 2013-02-20 at 08:36 -0500, Nicolas Pitre wrote:
> > You'll have the same issue wrt the above whether or not the source
> > file is C or assembly.
>
> Hm, true. I was thinking of the code itself (which is
> position-independent anyway), rather
On Wed, 2013-02-20 at 08:36 -0500, Nicolas Pitre wrote:
> You'll have the same issue wrt the above whether or not the source
> file is C or assembly.
Hm, true. I was thinking of the code itself (which is
position-independent anyway), rather than the flags in the object file.
So just ship a .S fil
On Wed, 20 Feb 2013, Woodhouse, David wrote:
> On Tue, 2013-02-19 at 22:17 -0500, Nicolas Pitre wrote:
> >
> > > +$(obj)/bswapsdi2.o: $(obj)/../../../../arch/$(SRCARCH)/lib/bswapsdi2.o
> > > + $(call cmd,shipped)
> > > +
> >
> > I don't think you can get away with this. The decompressor cod
On Tue, 2013-02-19 at 22:17 -0500, Nicolas Pitre wrote:
>
> > +$(obj)/bswapsdi2.o: $(obj)/../../../../arch/$(SRCARCH)/lib/bswapsdi2.o
> > + $(call cmd,shipped)
> > +
>
> I don't think you can get away with this. The decompressor code is
> compiled with -fpic and the main kernel is not. Mos
On Tue, 19 Feb 2013, Kim Phillips wrote:
> On Fri, 8 Feb 2013 22:16:47 -0500
> Nicolas Pitre wrote:
>
> > Not only that, but in many cases the results are wildly different given
> > the same config:
> >
> > > imx_v6_v7_defconfig: 7637605 7636935 -670
> > > lart_defconfig:
On 2/19/2013 6:31 PM, Kim Phillips wrote:
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index af72969..dbee639 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -45,3 +45,5 @@ lib-$(CONFIG_ARCH_SHARK)+= io-shark.o
>
> $(obj)/csumpartialcopy.o:$(obj)
On Fri, 8 Feb 2013 22:16:47 -0500
Nicolas Pitre wrote:
> On Fri, 8 Feb 2013, Kim Phillips wrote:
>
> > On Fri, 8 Feb 2013 17:47:33 -0500
> > Nicolas Pitre wrote:
> >
> > > On Fri, 8 Feb 2013, Woodhouse, David wrote:
> > >
> > > > On Fri, 2013-02-08 at 15:04 -0500, Nicolas Pitre wrote:
> > > >
On Fri, 8 Feb 2013, Kim Phillips wrote:
> On Fri, 8 Feb 2013 17:47:33 -0500
> Nicolas Pitre wrote:
>
> > On Fri, 8 Feb 2013, Woodhouse, David wrote:
> >
> > > On Fri, 2013-02-08 at 15:04 -0500, Nicolas Pitre wrote:
> > > > On Fri, 8 Feb 2013, Woodhouse, David wrote:
> > > >
> > > > > On Thu, 2
On Fri, 8 Feb 2013 17:47:33 -0500
Nicolas Pitre wrote:
> On Fri, 8 Feb 2013, Woodhouse, David wrote:
>
> > On Fri, 2013-02-08 at 15:04 -0500, Nicolas Pitre wrote:
> > > On Fri, 8 Feb 2013, Woodhouse, David wrote:
> > >
> > > > On Thu, 2013-02-07 at 18:13 +, Russell King - ARM Linux wrote:
>
On Fri, 8 Feb 2013, Woodhouse, David wrote:
> On Fri, 2013-02-08 at 15:04 -0500, Nicolas Pitre wrote:
> > On Fri, 8 Feb 2013, Woodhouse, David wrote:
> >
> > > On Thu, 2013-02-07 at 18:13 +, Russell King - ARM Linux wrote:
> > > >
> > > > However, the biggest reason not to use libgcc is that
On Fri, 2013-02-08 at 15:04 -0500, Nicolas Pitre wrote:
> On Fri, 8 Feb 2013, Woodhouse, David wrote:
>
> > On Thu, 2013-02-07 at 18:13 +, Russell King - ARM Linux wrote:
> > >
> > > However, the biggest reason not to use libgcc is that we want to control
> > > what gets used in the kernel -
On Fri, 8 Feb 2013, Woodhouse, David wrote:
> On Thu, 2013-02-07 at 18:13 +, Russell King - ARM Linux wrote:
> >
> > However, the biggest reason not to use libgcc is that we want to control
> > what gets used in the kernel - for example, no floating point, and no
> > use of 64 x 64bit divisio
On Thu, 2013-02-07 at 18:13 +, Russell King - ARM Linux wrote:
>
> However, the biggest reason not to use libgcc is that we want to control
> what gets used in the kernel - for example, no floating point, and no
> use of 64 x 64bit division.
Which is all very sensible. But there's no particul
On Wed, Feb 06, 2013 at 07:19:05PM -0600, Kim Phillips wrote:
> either that, or link with libgcc - why does arch/arm64 do this and
> arch/arm not? It's not obvious from git log.
We want to be in control of what code the kernel runs, and that means
not using libgcc. libgcc can do all sorts of stu
On 7 February 2013 10:19, Will Newton wrote:
> On Thu, Feb 7, 2013 at 1:19 AM, Kim Phillips
> wrote:
>> On Wed, 6 Feb 2013 09:02:04 +
>> "Woodhouse, David" wrote:
>>
>>> On Tue, 2013-02-05 at 21:04 -0600, Kim Phillips wrote:
>>> > gcc -Os emits calls to __bswapsi2 on those platforms to save
On Thu, Feb 7, 2013 at 1:19 AM, Kim Phillips wrote:
> On Wed, 6 Feb 2013 09:02:04 +
> "Woodhouse, David" wrote:
>
>> On Tue, 2013-02-05 at 21:04 -0600, Kim Phillips wrote:
>> > gcc -Os emits calls to __bswapsi2 on those platforms to save space
>> > because they don't have the single rev byte
On Wed, 6 Feb 2013 09:02:04 +
"Woodhouse, David" wrote:
> On Tue, 2013-02-05 at 21:04 -0600, Kim Phillips wrote:
> > gcc -Os emits calls to __bswapsi2 on those platforms to save space
> > because they don't have the single rev byte swap instruction.
>
> Is that the right thing for GCC to do
On Tue, 2013-02-05 at 21:04 -0600, Kim Phillips wrote:
> gcc -Os emits calls to __bswapsi2 on those platforms to save space
> because they don't have the single rev byte swap instruction.
Is that the right thing for GCC to do in that situation?
If so, perhaps we should be *providing* __bswap[sd]i
On Fri, 1 Feb 2013 07:33:17 +
"Woodhouse, David" wrote:
> On Fri, 2013-02-01 at 01:17 +, Russell King - ARM Linux wrote:
> >
> > > I've tried both gcc 4.6.3 [1] and 4.6.4 [2]. If you can point me to
> > > a 4.5.x, I'll try that, too, but as it stands now, if one moves the
> > > code add
On Fri, 2013-02-01 at 01:17 +, Russell King - ARM Linux wrote:
>
> > I've tried both gcc 4.6.3 [1] and 4.6.4 [2]. If you can point me to
> > a 4.5.x, I'll try that, too, but as it stands now, if one moves the
> > code added to swab.h below outside of its armv6 protection,
> > gcc adds calls t
On Thu, Jan 31, 2013 at 02:59:47PM -0600, Kim Phillips wrote:
> On Thu, 31 Jan 2013 09:28:01 +
> Russell King - ARM Linux wrote:
>
> > On Wed, Jan 30, 2013 at 08:09:00PM -0600, Kim Phillips wrote:
> > > v2:
> > > - at91 and lpd270 builds fixed by limiting to ARMv6 and above
> > > (i.e., ARM
On Thu, 2013-01-31 at 14:59 -0600, Kim Phillips wrote:
>
> - add new ARCH_DEFINES_BUILTIN_BSWAP (see Kconfig help).
Ick, no.
> - if set, generic compiler header does not set HAVE_BUILTIN_BSWAPxx
It won't do that anyway if !ARCH_USE_BUILTIN_BSWAP. I don't see the
point in adding a new config o
On Thu, Jan 31, 2013 at 02:59:47PM -0600, Kim Phillips wrote:
> - add new ARCH_DEFINES_BUILTIN_BSWAP (see Kconfig help).
> - if set, generic compiler header does not set HAVE_BUILTIN_BSWAPxx
> - not too sure about this having to be a new CONFIG_, but it's hard
> to find a place for it given
On Thu, 31 Jan 2013 09:28:01 +
Russell King - ARM Linux wrote:
> On Wed, Jan 30, 2013 at 08:09:00PM -0600, Kim Phillips wrote:
> > The savings come mostly from device-tree related code, and some
> > from drivers.
>
> You forget that IP networking is all big endian, so these will be using
> t
A quick test showed I only dropped 20 bytes from net/ipv4/built-in.o but that's
with no 16-bit swap support (gcc 4.7).
--
dwmw2
(Apologies for HTML and top-posting; Android mailer is broken.)
On Wed, Jan 30, 2013 at 08:09:00PM -0600, Kim Phillips wrote:
> The savings come mostly from device-tree related code, and some
> from drivers.
You forget that IP networking is all big endian, so these will be using
the byte swapping too (search it for htons/ntohs/htonl/ntohl).
> v2:
> - at91 and
On Wed, Jan 30, 2013 at 08:09:00PM -0600, Kim Phillips wrote:
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 40e2b12..c8798b9 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -141,6 +141,16 @@ config ARCH_USE_BUILTIN_BSWAP
>instructions should set this. And it shouldn't hurt to set
On Wed, 30 Jan 2013 10:22:15 +
"Woodhouse, David" wrote:
> On Tue, 2013-01-29 at 19:10 +0100, Borislav Petkov wrote:
> > So, IMHO it sounds to me like we want to explicitly state for each arch
> > separately that it is ok to use the __builtin_bswapXX things. This also
> > takes care of the ca
On Tue, 2013-01-29 at 19:10 +0100, Borislav Petkov wrote:
> So, IMHO it sounds to me like we want to explicitly state for each arch
> separately that it is ok to use the __builtin_bswapXX things. This also
> takes care of the case where the compiler is doing something suboptimal
> by excluding the
On Tue, Jan 29, 2013 at 05:55:54PM +, Woodhouse, David wrote:
> That's different though. That's because GCC didn't have a generic
> __builtin_bswap16() until 4.8, while PowerPC got it in 4.6.
>
> That's a relatively simple and manageable one-off arch-dependency. But
> once we get into a mass o
On Tue, 2013-01-29 at 18:42 +0100, Borislav Petkov wrote:
> On Tue, Jan 29, 2013 at 04:46:58PM +, Woodhouse, David wrote:
> > If we're really going to have many different architectures depending
> > on different versions of GCC for this (if it wasn't sane to use
> > it from 4.4/4.8 when it got
On Tue, Jan 29, 2013 at 04:46:58PM +, Woodhouse, David wrote:
> If we're really going to have many different architectures depending
> on different versions of GCC for this (if it wasn't sane to use
> it from 4.4/4.8 when it got introduced, and depends on some later
> arch-specific optimisation
On Tue, 2013-01-29 at 09:35 +0100, Borislav Petkov wrote:
>
> >
> > #ifdef CONFIG_ARCH_USE_BUILTIN_BSWAP
> > -#if GCC_VERSION >= 40400
> > +#if (!defined(__arm__) && GCC_VERSION >= 40400) || \
> > +(defined(__arm__) && GCC_VERSION >= 40600)
>
> There should be no arch-specific stuff in a g
On Tue, 2013-01-29 at 08:53 -0600, Rob Herring wrote:
> If you specify to use the builtin's, do you still get inline rev
> instructions emitted?
You mean from the architecture's __arch_swab32() et al. macros?
No. If the architecture enables ARCH_USE_BUILTIN_BSWAP and the compiler
version checks i
On 01/28/2013 07:30 PM, Kim Phillips wrote:
> Enable the compiler intrinsic for byte swapping on arch ARM. This
> allows the compiler to detect and be able to optimize out byte
> swappings, e.g. in big endian to big endian moves.
>
> AFAICT, arm gcc got __builtin_bswap{32,64} support in 4.6,
> an
On Tue, 2013-01-29 at 14:13 +, Russell King - ARM Linux wrote:
>
> So, this compiler (4.5.4) has support for 32-bit and 64-bit bswaps
> across all our architectures, but not the 16-bit ones.
That observation is consistent with my dig through GCC history. I had
come to the conclusion that the
On Mon, Jan 28, 2013 at 07:30:33PM -0600, Kim Phillips wrote:
> AFAICT, arm gcc got __builtin_bswap{32,64} support in 4.6,
> and for the 16-bit version in 4.8.
Hmm.
$ /usr/local/aeabi/bin/arm-linux-gcc --version
arm-linux-gcc (GCC) 4.5.4
Copyright (C) 2010 Free Software Foundation, Inc.
This is f
On Mon, Jan 28, 2013 at 07:30:33PM -0600, Kim Phillips wrote:
> Enable the compiler intrinsic for byte swapping on arch ARM. This
> allows the compiler to detect and be able to optimize out byte
> swappings, e.g. in big endian to big endian moves.
>
> AFAICT, arm gcc got __builtin_bswap{32,64} su
Enable the compiler intrinsic for byte swapping on arch ARM. This
allows the compiler to detect and be able to optimize out byte
swappings, e.g. in big endian to big endian moves.
AFAICT, arm gcc got __builtin_bswap{32,64} support in 4.6,
and for the 16-bit version in 4.8.
Signed-off-by: Kim Phi
50 matches
Mail list logo