: powerpc: Fix build breakage due to incorrect location of autoconf.h

commit ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 (zlib: optimize inffast when copying direct from output) referenced include/linux/autoconf.h which is now called include/generated/autoconf.h.

Hi Anton,

Quoted 1 line · On Tue, 12 Jan 2010 13:21:51 +1100 Anton Blanchard <[email protected]> wrote:

Quoted 3 lines

commit ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 (zlib: optimize inffast when copying direct from output) referenced include/linux/autoconf.h which is now called include/generated/autoconf.h.

Even with this fix, you cannot build with a separate object directory. See my other posting "linux-next: origin tree build failure" ... --

From 044f40d169bf5fe189d5cb058f56b7cd72675ca4 Mon Sep 17 00:00:00 2001

Quoted 4 lines

=20
Hi Anton,
=20
On Tue, 12 Jan 2010 13:21:51 +1100 Anton Blanchard <[email protected]> =

Quoted 2 lines

Quoted 2 lines

=20
commit ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 (zlib: optimize =

Quoted 1 line

Quoted 1 line

copying direct from output) referenced include/linux/autoconf.h =

Quoted 3 lines

Quoted 1 line

is now called include/generated/autoconf.h.

=20
Even with this fix, you cannot build with a separate object =

Quoted 2 lines

See my other posting "linux-next: origin tree build failure" ... --

=20
How does this work for you?
=20

Quoted 1 line

=46rom 044f40d169bf5fe189d5cb058f56b7cd72675ca4 Mon Sep 17 00:00:00 =

From: Joakim Tjernlund <[email protected]>
Date: Tue, 12 Jan 2010 11:20:36 +0100
Subject: [PATCH] powerpc: Fix build breakage due to incorrect location =

=20
commit ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 (zlib: optimize =

copying direct from output) referenced include/linux/autoconf.h which is now called include/generated/autoconf.h.
Also, -I include paths needs to be prefixed with $(srctree) =20

Signed-off-by Joakim Tjernlund <[email protected]>

---
arch/powerpc/boot/Makefile | 4 ++--

1 files changed, 2 insertions(+), 2 deletions(-)

=20

arch/powerpc/boot/Makefile +0 -0

index 826a30a..79ebd6f 100644
@@ -34,8 +34,8 @@ BOOTCFLAGS	+=3D -fno-stack-protector

endif
=20
BOOTCFLAGS +=3D -I$(obj) -I$(srctree)/$(obj)
-BOOTCFLAGS +=3D -include include/linux/autoconf.h =

=20
DTS_FLAGS ?=3D -p 1024
=20

Quoted 7 lines

BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)

arch/powerpc/boot/Makefile +2 -2

-BOOTCFLAGS	+= -include include/linux/autoconf.h -Iarch/powerpc/include
-BOOTCFLAGS	+= -Iinclude
+BOOTCFLAGS	+= -include include/generated/autoconf.h
+BOOTCFLAGS	+= -I$(srctree)/arch/powerpc/include -I$(srctree)/include

Quoted 2 lines

DTS_FLAGS ?= -p 1024

Ack, this works for me (seeing as -rc4 doesn't generate uImages w/o it :)

Quoted 8 lines

Quoted 8 lines

BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)

arch/powerpc/boot/Makefile +2 -2

-BOOTCFLAGS   += -include include/linux/autoconf.h -Iarch/powerpc/include
-BOOTCFLAGS   += -Iinclude
+BOOTCFLAGS   += -include include/generated/autoconf.h
+BOOTCFLAGS   += -I$(srctree)/arch/powerpc/include -I$(srctree)/include

Quoted 5 lines

Quoted 2 lines

DTS_FLAGS ?= -p 1024

Ack, this works for me (seeing as -rc4 doesn't generate uImages w/o it :)

I sent a different patch to Linus yesterday for that.

Seen it now as it is in Linus tree:

1) IMHO it would have been nicer to use #ifdef __KERNEL__ instead of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
as then arches that don't define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS at all will never use the new optimization or was that what you intended?

2) You really should add an comment in the Makefile about not using autoconf.h/-D__KERNEL__

Subject: Re: [PATCH]: powerpc: Fix build breakage due to incorrect location ofautoconf.h

Quoted 6 lines

Seen it now as it is in Linus tree:

1) IMHO it would have been nicer to use #ifdef __KERNEL__ instead of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
as then arches that don't define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS at all will never use the new optimization or was that what you intended?

No, that was on purpose. If an arch doesn't have efficient unaligned accesses, then they should not use the optimization since it will result in a lot of unaligned accesses :-) In which case they are better off falling back to the old byte-by-byte method.

The advantage also of doing it this way is that x86 will benefit from the optimisation at boot time since it does include autoconf.h in its

boot wrapper (and deals with unaligned accesses just fine at any time) though something tells me that it won't make much of a difference in performances on any recent x86 (it might on some of the newer low power embedded ones, I don't know for sure).

Quoted 2 lines

No, that was on purpose. If an arch doesn't have efficient unaligned accesses, then they should not use the optimization since it will

result

Quoted 2 lines

in a lot of unaligned accesses :-) In which case they are better off falling back to the old byte-by-byte method.

Not quite, it is only 1 of 4 accesses that uses unaligned and that accesses is only unaligned 50% in average, it might still be faster. We will never know now.

Quoted 9 lines

Quoted 2 lines

No, that was on purpose. If an arch doesn't have efficient unaligned accesses, then they should not use the optimization since it will

result

Quoted 2 lines

in a lot of unaligned accesses :-) In which case they are better off falling back to the old byte-by-byte method.

Not quite, it is only 1 of 4 accesses that uses unaligned and that accesses is only unaligned 50% in average, it might still be faster. We will never know now.

Why ? If you think it's a win, then it's easy to make a patch to turn it to __KERNEL__ and ask some people from ARM and MIPS or even sparc land for example to give it a spin. If it's indeed a win, then submit it to Linus and/or Andrew and there's no reason for it not to go in.

I simply took a more conservative approach for post -rc4

Quoted 9 lines

Quoted 2 lines

No, that was on purpose. If an arch doesn't have efficient unaligned accesses, then they should not use the optimization since it will

result

Quoted 2 lines

in a lot of unaligned accesses :-) In which case they are better off falling back to the old byte-by-byte method.

Not quite, it is only 1 of 4 accesses that uses unaligned and that accesses is only unaligned 50% in average, it might still be faster. We will never know now.

Why ? If you think it's a win, then it's easy to make a patch to turn it to __KERNEL__ and ask some people from ARM and MIPS or even sparc land for example to give it a spin. If it's indeed a win, then submit it to Linus and/or Andrew and there's no reason for it not to go in.

I simply took a more conservative approach for post -rc4

It would probably be a good idea to redefine UP_UNALIGNED macro to do 2 byte accesses in the non CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS case.

I don't think I will revisit this any time soon so I figured I should mention it in case someone else wants to try it.

Quoted 8 lines

Seen it now as it is in Linus tree:

1) IMHO it would have been nicer to use #ifdef __KERNEL__ instead of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
as then arches that don't define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS at all will never use the new optimization or was that what you intended?

No, that was on purpose. If an arch doesn't have efficient unaligned accesses, then they should not use the optimization since it will result in a lot of unaligned accesses :-) In which case they are better off falling back to the old byte-by-byte method.

The advantage also of doing it this way is that x86 will benefit from the optimisation at boot time since it does include autoconf.h in its boot wrapper (and deals with unaligned accesses just fine at any time) though something tells me that it won't make much of a difference in performances on any recent x86 (it might on some of the newer low power embedded ones, I don't know for sure).

Quoted 2 lines

2) You really should add an comment in the Makefile about not using autoconf.h/-D__KERNEL__

That's true :-)

From 4e769486e2520e34f532a2d4bf13ab13f05e3e76 Mon Sep 17 00:00:00 2001

Benjamin Herrenschmidt <[email protected]> wrote on 2010/01/14 09:57:11:

Quoted 21 lines

Quoted 8 lines

Seen it now as it is in Linus tree:

1) IMHO it would have been nicer to use #ifdef __KERNEL__ instead of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
as then arches that don't define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS at all will never use the new optimization or was that what you intended?

No, that was on purpose. If an arch doesn't have efficient unaligned accesses, then they should not use the optimization since it will result in a lot of unaligned accesses :-) In which case they are better off falling back to the old byte-by-byte method.

The advantage also of doing it this way is that x86 will benefit from the optimisation at boot time since it does include autoconf.h in its boot wrapper (and deals with unaligned accesses just fine at any time) though something tells me that it won't make much of a difference in performances on any recent x86 (it might on some of the newer low power embedded ones, I don't know for sure).

Quoted 4 lines

Quoted 2 lines

2) You really should add an comment in the Makefile about not using autoconf.h/-D__KERNEL__

That's true :-)

So I fixed the new inflate to be endian independent and now all arches can use the optimized version. Here goes:

From 4e769486e2520e34f532a2d4bf13ab13f05e3e76 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <[email protected]>
Date: Sun, 24 Jan 2010 11:12:56 +0100
Subject: [PATCH] zlib: Make new optimized inflate endian independent

Commit 6846ee5ca68d81e6baccf0d56221d7a00c1be18b made the new optimized inflate only available on arch's that define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS. This fixes it by defining our own endian independent versions of unaligned access.

Signed-off-by Joakim Tjernlund <[email protected]>

---
 lib/zlib_inflate/inffast.c |   70 +++++++++++++++++++-------------------------
 1 files changed, 30 insertions(+), 40 deletions(-)

lib/zlib_inflate/inffast.c +30 -41

index 215447c..5de16f4 100644
@@ -8,21 +8,6 @@
 #include "inflate.h"
 #include "inffast.h"
 
-/* Only do the unaligned "Faster" variant when
- * CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set
- *
- * On powerpc, it won't be as we don't include autoconf.h
- * automatically for the boot wrapper, which is intended as
- * we run in an environment where we may not be able to deal
- * with (even rare) alignment faults. In addition, we do not
- * define __KERNEL__ for arch/powerpc/boot unlike x86
- */
-
-#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
-#include <asm/unaligned.h>
-#include <asm/byteorder.h>
-#endif
-
 #ifndef ASMINF
 
 /* Allow machine dependent optimization for post-increment or pre-increment.

@@ -36,14 +21,31 @@
    - Pentium III (Anderson)
    - M68060 (Nikl)
  */
+union uu {
+   unsigned short us;
+   unsigned char b[2];
+};
+
+/* Endian independed version */
+static inline unsigned short
+get_unaligned16(const unsigned short *p)
+{
+   union uu  mm;
+   unsigned char *b = (unsigned char *)p;
+
+   mm.b[0] = b[0];
+   mm.b[1] = b[1];
+   return mm.us;
+}
+
 #ifdef POSTINC
 #  define OFF 0
 #  define PUP(a) *(a)++
-#  define UP_UNALIGNED(a) get_unaligned((a)++)
+#  define UP_UNALIGNED(a) get_unaligned16((a)++)
 #else
 #  define OFF 1
 #  define PUP(a) *++(a)
-#  define UP_UNALIGNED(a) get_unaligned(++(a))
+#  define UP_UNALIGNED(a) get_unaligned16(++(a))
 #endif
 
 /*

@@ -256,7 +258,6 @@ void inflate_fast(z_streamp strm, unsigned start)
                     }
                 }
                 else {
-#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
           unsigned short *sout;
           unsigned long loops;
 

@@ -274,7 +275,11 @@ void inflate_fast(z_streamp strm, unsigned start)
          sfrom = (unsigned short *)(from - OFF);
          loops = len >> 1;
          do
+#ifdef  CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
+             PUP(sout) = PUP(sfrom);
+#else
              PUP(sout) = UP_UNALIGNED(sfrom);
+#endif
          while (--loops);
          out = (unsigned char *)sout + OFF;
          from = (unsigned char *)sfrom + OFF;

@@ -282,14 +287,13 @@ void inflate_fast(z_streamp strm, unsigned start)
          unsigned short pat16;
 
          pat16 = *(sout-2+2*OFF);
-         if (dist == 1)
-#if defined(__BIG_ENDIAN)
-             pat16 = (pat16 & 0xff) | ((pat16 & 0xff) << 8);
-#elif defined(__LITTLE_ENDIAN)
-             pat16 = (pat16 & 0xff00) | ((pat16 & 0xff00) >> 8);
-#else
-#error __BIG_ENDIAN nor __LITTLE_ENDIAN is defined
-#endif
+         if (dist == 1) {
+            union uu mm;
+            /* copy one char pattern to both bytes */
+            mm.us = pat16;
+            mm.b[0] = mm.b[1];
+            pat16 = mm.us;
+         }
          loops = len >> 1;
          do
              PUP(sout) = pat16;

@@ -298,20 +302,6 @@ void inflate_fast(z_streamp strm, unsigned start)
           }
           if (len & 1)
          PUP(out) = PUP(from);
-#else /* CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS */
-                    from = out - dist;          /* copy direct from output */
-                    do {                        /* minimum length is three */
-          PUP(out) = PUP(from);
-          PUP(out) = PUP(from);
-          PUP(out) = PUP(from);
-          len -= 3;
-                    } while (len > 2);
-                    if (len) {
-          PUP(out) = PUP(from);
-          if (len > 1)
-              PUP(out) = PUP(from);
-                    }
-#endif /* !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS */
                 }
             }
             else if ((op & 64) == 0) {          /* 2nd level distance code */
--

1.6.4.4

_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev

Commit 6846ee5ca68d81e6baccf0d56221d7a00c1be18b made the new optimized inflate only available on arch's that define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS. This fixes it by defining our own endian independent versions of unaligned access.

On Mon, 25 Jan 2010 09:19:59 +0100
Joakim Tjernlund <[email protected]> wrote:

Quoted 5 lines

Commit 6846ee5ca68d81e6baccf0d56221d7a00c1be18b made the new optimized inflate only available on arch's that define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS. This fixes it by defining our own endian independent versions of unaligned access.

(I hope I picked up the right version of whatever-it-was-i-was-supposed-to-pick-up - I wasn't paying attention).

The changelog sucks. You say the patch fixes "it", but what is "it"? Is "it" a build error? If so, what? Or is "it" a make-optimized-inflate-available-on-ppc patch, in which case it's a "feature"?

From 612bfb4cc6cc55243c2a4f536ae2ae71065b57b0 Mon Sep 17 00:00:00 2001

Commit 6846ee5ca68d81e6baccf0d56221d7a00c1be18b made the new optimized inflate only available on arch's that define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS. This will again enable the optimization for all arch's by by defining our own endian independent version of unaligned access. As an added bonus, arch's that define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS do a plain load instead.

Quoted 8 lines · On Thu, 28 Jan 2010 09:52:41 +0100 Joakim Tjernlund…

Commit 6846ee5ca68d81e6baccf0d56221d7a00c1be18b made the new optimized inflate only available on arch's that define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS. This will again enable the optimization for all arch's by by defining our own endian independent version of unaligned access. As an added bonus, arch's that define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS do a plain load instead.

Given that we're at -rc5, that changelog says to me "this is a 2.6.34 patch".

If that is wrong, please tell me why.

commit ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 (zlib: optimize inffast when copying direct from output) referenced include/linux/autoconf.h which is now called include/generated/autoconf.h.

Signed-off-by Anton Blanchard <[email protected]>

---

Index: linux-cpumask/arch/powerpc/boot/Makefile
===================================================================