iwwmmxt optimization and soft float in OE on PXA270

iwwmmxt optimization and soft float in OE on PXA270

[Stanislav Brabec]

Hallo.

What is your opinion on enabling of iwmmxt optimization on >=PXA270
devices, and optionally also soft floats?

I read old posts talking regarding broken iwmmxt support in gcc.

I also read something about float emulation options for PXA270, its
speed and ABI breakage. It seems, that soft float should be the fastest
option for devices without hardware FPU.

I wanted to test it and I have recompiled everything I am using with:
-march=iwmmxt -mcpu=iwmmxt -mtune=iwmmxt -Os -funswitch-loops -fgcse-after-reload -msoft-float

It should be the best possible optimization for PXA270 (compiled for
iwmmxt, use soft float instead of exception based kernel driver, use -Os
to make binaries as small as possible and add optimizations from -O3).

Then I have created a spitz feed based on the latest OE.dev and
installed.

Here is iwmmxt soft float Spitz feed:
http://www.penguin.cz/~utx/zaurus/feed/
(You have to degrade or remove xorg-kdrive before boot - known bug. You
have to replace the default feed by the experimental one. And finally,
2.6.24 is available in the feed and you can upgrade.)

Problems relevant to iwmmxt:
- qemu does not work properly and fails to compile locales, timezones
  and emacs.
- minimo compilation fails (not yet analyzed)

Problems relevant to soft float:
- Breaks ABI of applications using math.

I am now using it for several days, and I don't see any problems, which
were not known with the default compiler.

Other results:
- Os does not create significantly smaller binaries when compared with
  the default -O2.
- Some applications seems to run a bit faster (MPlayer).


________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: iwwmmxt optimization and soft float in OE on PXA270

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stanislav Brabec schreef:

| It should be the best possible optimization for PXA270 (compiled for
| iwmmxt, use soft float instead of exception based kernel driver, use -Os
| to make binaries as small as possible and add optimizations from -O3).

Angstrom already enables softfloat (for FPU-less systems) and -Os by
default *and* enables iwmmxt (if you have MACHINE_FEATURES = "iwmmxt")
for apps which have been proven to benefit from iwmmxt (e.g. mplayer).

I still get mysterious segfaults when running an all iwmmxt glibc system
(uclibc is even worse), so I don't think flipping the global switch is a
good idea.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHy6jAMkyGM64RGpERAsGmAKCQBrKr7a0LdUqRStpIDORkk+qS9wCgmmQv
ymohRaCAWpT3vX88U2/vSaI=
=83mT
-----END PGP SIGNATURE-----

Re: iwwmmxt optimization and soft float in OE on PXA270

[Stanislav Brabec]

Koen Kooi wrote:

> Angstrom already enables softfloat (for FPU-less systems) and -Os by
> default *and* enables iwmmxt (if you have MACHINE_FEATURES = "iwmmxt")
> for apps which have been proven to benefit from iwmmxt (e.g. mplayer).

Ah, I see. ABI-compatible softfp mode is enabled by patching gcc, not in
conf files.

> I still get mysterious segfaults when running an all iwmmxt glibc system
> (uclibc is even worse), so I don't think flipping the global switch is a
> good idea.

Which applications are failing for you?

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: iwwmmxt optimization and soft float in OE on PXA270

[Khem Raj]

Stanislav,

What ABI breakage are you seeing ?
Aren't you using EABI ?

Thanks

-Khem

On Mon, Mar 3, 2008 at 2:48 AM, Stanislav Brabec <utx@penguin.cz> wrote:
> Koen Kooi wrote:
>
>  > Angstrom already enables softfloat (for FPU-less systems) and -Os by
>  > default *and* enables iwmmxt (if you have MACHINE_FEATURES = "iwmmxt")
>  > for apps which have been proven to benefit from iwmmxt (e.g. mplayer).
>
>  Ah, I see. ABI-compatible softfp mode is enabled by patching gcc, not in
>  conf files.
>
>
>  > I still get mysterious segfaults when running an all iwmmxt glibc system
>  > (uclibc is even worse), so I don't think flipping the global switch is a
>  > good idea.
>
>  Which applications are failing for you?
>
>  --
>
> Stanislav Brabec
>  http://www.penguin.cz/~utx/zaurus
>
>
>  _______________________________________________
>
>
> Openembedded-devel mailing list
>  Openembedded-devel@lists.openembedded.org
>  http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: iwwmmxt optimization and soft float in OE on PXA270

[Stanislav Brabec]

Khem Raj wrote: 
> Stanislav,
> 
> What ABI breakage are you seeing ?
> Aren't you using EABI ?

I didn't check this yet, but gcc(1) talks about it. If I understand
correctly, -mfloat-abi=hard uses FPU or exception based code in kernel,
-mfloat-abi=softfp uses software float and ABI equal to hard-float, and
-msoft-float (or -mfloat-abi=soft) breaks ABI and uses different ABI.

Please fix me, if I am wrong. I don't have deep insight into this
problem, so I have exactly followed recommendation and recompiled
everything after this change.


Manual page gcc(1) 57%:

-msoft-float
    Generate output containing library calls for floating point.  Warn‐
    ing: the requisite libraries are not available for all ARM targets.
    Normally the facilities of the machine's usual C compiler are used,
    but this cannot be done directly in cross-compilation.  You must
    make your own arrangements to provide suitable library functions
    for cross-compilation.

    -msoft-float changes the calling convention in the output file;
    therefore, it is only useful if you compile all of a program with
    this option.  In particular, you need to compile libgcc.a, the
    library that comes with GCC, with -msoft-float in order for this to
    work.

-mfloat-abi=name
    Specifies which ABI to use for floating point values.  Permissible
    values are: soft, softfp and hard.

    soft and hard are equivalent to -msoft-float and -mhard-float
    respectively.  softfp allows the generation of floating point
    instructions, but still uses the soft-float calling conventions.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: iwwmmxt optimization and soft float in OE on PXA270

[Stanislav Brabec]

Stanislav Brabec wrote:

> Khem Raj wrote: 
> > What ABI breakage are you seeing ?
> > Aren't you using EABI ?
I have verified, that gcc(1) does not tell true, and I see no breakage
while mixing these two environments (library from one x binary from
second one).

It allows me to do small benchmarks - compare default image with
optimized iwmmxt image.

I see about 13% performance improvement. I don't yet know why.

previous (mid-February) oe.dev image in chroot, compiled with defaults:
armv5, only mplayer for iwmmxt, softfp floats, reusing original kernel
and X:
2nd run:
real	0m26.696s
user	0m7.700s
sys	0m1.030s
3rd run:
real	0m26.611s
user	0m7.570s
sys	0m0.880s

playing video, everything compiled for iwmmxt with -msoft-float and
higher optimization options:
2nd run:
real	0m25.990s
user	0m6.840s
sys	0m0.830s
3rd run:
real	0m25.964s
user	0m6.700s
sys	0m0.760s

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: iwmmxt optimization and soft float in OE on PXA270

[Hasjim Williams]

On Mon, 03 Mar 2008 08:29:04 +0100, "Koen Kooi"
<koen@dominion.kabel.utwente.nl> said:
> Stanislav Brabec schreef:
> 
> | It should be the best possible optimization for PXA270 (compiled for
> | iwmmxt, use soft float instead of exception based kernel driver, use
> -Os
> | to make binaries as small as possible and add optimizations from -O3).
> 
> Angstrom already enables softfloat (for FPU-less systems) and -Os by
> default *and* enables iwmmxt (if you have MACHINE_FEATURES = "iwmmxt")
> for apps which have been proven to benefit from iwmmxt (e.g. mplayer).
> 
> I still get mysterious segfaults when running an all iwmmxt glibc system
> (uclibc is even worse), so I don't think flipping the global switch is a
> good idea.

You won't be able to use iwmmxt with everything.  The unwind / exception
support for iwxmmt isn't there in gcc.  Anything using C++ exceptions
won't work correctly.

infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf
explains about the unwind / exceptions.

This is also one of the issues that Cirrus's MaverickCrunch currently
has.

The only ARM coprocessor that is fully supported (by gcc) is VFP.  

In summary, we'd have to modify:
gcc/config/arm/pr-support.c
gcc/config/arm/unwind-arm.h
gcc/config/arm/unwind-arm.c

for proper iwmmxt Unwind_VRS_Pop support.

NB, I'm the guy that has done the MaverickCrunch gcc patches...

I could write/test these patches, I guess, but the only PXA270 machine
that I have access to is a HTC Magician (XDA Mini).

Hasjim Williams

Re: iwmmxt optimization and soft float in OE on PXA270

[Stanislav Brabec]

Hasjim Williams wrote:

> You won't be able to use iwmmxt with everything.  The unwind / exception
> support for iwxmmt isn't there in gcc.  Anything using C++ exceptions
> won't work correctly.

So plain C binaries (e. g. kernel) are OK? And
c++ -march=iwmmxt -fno-exceptions as well?

> infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf
> explains about the unwind / exceptions.
> 
> This is also one of the issues that Cirrus's MaverickCrunch currently
> has.
> 
> The only ARM coprocessor that is fully supported (by gcc) is VFP.  
> 
> In summary, we'd have to modify:
> gcc/config/arm/pr-support.c
> gcc/config/arm/unwind-arm.h
> gcc/config/arm/unwind-arm.c
> 
> for proper iwmmxt Unwind_VRS_Pop support.
> 
> NB, I'm the guy that has done the MaverickCrunch gcc patches...
> 
> I could write/test these patches, I guess, but the only PXA270 machine
> that I have access to is a HTC Magician (XDA Mini).

It would be very nice. I could test them on my Zaurus, if you send me
some C++ testcase (or name of application to test it on).

The last missing thing - iwmmxt support in qemu - was already written by
Andrzej Zaborowski.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: iwmmxt optimization and soft float in OE on PXA270

[Hasjim Williams]

On Thu, 20 Mar 2008 13:46:15 +0100, "Stanislav Brabec" <utx@penguin.cz>
said:
> Hasjim Williams wrote:
> 
> > You won't be able to use iwmmxt with everything.  The unwind / exception
> > support for iwxmmt isn't there in gcc.  Anything using C++ exceptions
> > won't work correctly.
> 
> So plain C binaries (e. g. kernel) are OK? And
> c++ -march=iwmmxt -fno-exceptions as well?

You can try this for C++ with -fno-exceptions, but I've never tried
it...

> > I could write/test these patches, I guess, but the only PXA270 machine
> > that I have access to is a HTC Magician (XDA Mini).
> 
> It would be very nice. I could test them on my Zaurus, if you send me
> some C++ testcase (or name of application to test it on).

It'd be good if you could run the tests, before we generate the
patches... 

gcc has a built in testcase system, dejagnu:
http://lists.gnu.org/archive/html/dejagnu/2006-04/msg00008.html explains
how to set it up and run it.
http://gcc.gnu.org/onlinedocs/libstdc++/test.html and 

e.g. FROM:
openembedded/build/tmp/work/armv4t-angstrom-linux-gnueabi/gcc-cross-4.1.2-r13/gcc-4.1.2/build.i686-linux.arm-angstrom-linux.arm-angstrom-linux-gnueabi
$ make check-gcc RUNTESTFLAGS="normal.exp --target_board=pxa270-linux"

I think the C++ support you're looking to test is in "normal.exp" .  You
should get a gcc.log and gcc.sum at the end, saying what tests
passed/failed.

$ make check
Will do a complete test of everything, and will probably take at least 8
hrs - day on a pxa270, I would think.

You'll only need dropbear or some other ssh server, so even a
minimal-image should be enough on your pxa27x machine.
 
> The last missing thing - iwmmxt support in qemu - was already written by
> Andrzej Zaborowski.

Is this "qemu-pxa270-and-more.patch" or is there something newer?  Has
this been put into OE's buildtree?

NB, Not sure what you're using to profile the speedups, but there is:

gcov:
http://gcc.gnu.org/onlinedocs/gcc/Gcov.html#Gcov

and gprof:
http://www.gnu.org/software/binutils/manual/gprof-2.9.1/gprof.html

Re: iwmmxt optimization and soft float in OE on PXA270

[Khem Raj]

On Thu, Mar 20, 2008 at 3:14 PM, Hasjim Williams
<openembedded-devel@lists.futaris.org> wrote:
>
>  On Thu, 20 Mar 2008 13:46:15 +0100, "Stanislav Brabec" <utx@penguin.cz>
>  said:
>
> > Hasjim Williams wrote:
>  >
>  > > You won't be able to use iwmmxt with everything.  The unwind / exception
>  > > support for iwxmmt isn't there in gcc.  Anything using C++ exceptions
>  > > won't work correctly.
>  >
>  > So plain C binaries (e. g. kernel) are OK? And
>  > c++ -march=iwmmxt -fno-exceptions as well?
>
>  You can try this for C++ with -fno-exceptions, but I've never tried
>  it...
>
>
>  > > I could write/test these patches, I guess, but the only PXA270 machine
>  > > that I have access to is a HTC Magician (XDA Mini).
>  >
>  > It would be very nice. I could test them on my Zaurus, if you send me
>  > some C++ testcase (or name of application to test it on).
>
>  It'd be good if you could run the tests, before we generate the
>  patches...
>
>  gcc has a built in testcase system, dejagnu:
>  http://lists.gnu.org/archive/html/dejagnu/2006-04/msg00008.html explains
>  how to set it up and run it.
>  http://gcc.gnu.org/onlinedocs/libstdc++/test.html and
>
>  e.g. FROM:
>  openembedded/build/tmp/work/armv4t-angstrom-linux-gnueabi/gcc-cross-4.1.2-r13/gcc-4.1.2/build.i686-linux.arm-angstrom-linux.arm-angstrom-linux-gnueabi
>  $ make check-gcc RUNTESTFLAGS="normal.exp --target_board=pxa270-linux"
>
>  I think the C++ support you're looking to test is in "normal.exp" .  You
>  should get a gcc.log and gcc.sum at the end, saying what tests
>  passed/failed.
>
>  $ make check
>  Will do a complete test of everything, and will probably take at least 8
>  hrs - day on a pxa270, I would think.
>
>  You'll only need dropbear or some other ssh server, so even a
>  minimal-image should be enough on your pxa27x machine.

yeah and also setup a passwordless entry into the target from host.
Otherwise it will ask for password everytime
it wants to talk to target. Dropbear asks for return carriage key for
empty passwords too. I havent figured to disable that
openssh works.

Khem

Re: iwmmxt optimization on PXA270 (dejagnu test report)

[Stanislav Brabec]

Hasjim Williams wrote:
> On Thu, 20 Mar 2008 13:46:15 +0100, "Stanislav Brabec"
> <utx@penguin.cz>
> said:

> > > I could write/test these patches, I guess, but the only PXA270 machine
> > > that I have access to is a HTC Magician (XDA Mini).
> > 
> > It would be very nice. I could test them on my Zaurus, if you send me
> > some C++ testcase (or name of application to test it on).
> 
> It'd be good if you could run the tests, before we generate the
> patches... 

I tested gcc-4.2.2-r6 with -march=iwmmxt -mcpu=iwmmxt -mtune=iwmmxt on
my image compiled for iwmmxt.

Results seems to be promising. 99.99% tests passed. Results for Fortran
are invalid (I had not libgfortran in the system). Surprisingly, all
g++.dg/eh (exception handling) tests PASSed.

Profiling tests has some problems - file is generated with different
suffix than expected.

Details:

                === gcc Summary ===
# of expected passes            40740
# of unexpected failures        15
  It consists of (my guess):
  probably real failure         4 (1 file, 4 flags)
  missing file in testsuite     11
# of expected failures          84
# of unresolved testcases       23
# of untested testcases         28
# of unsupported tests          394

                === g++ Summary ===
# of expected passes            13403
# of unexpected failures        20
  It consists of (my guess):
  missing file in testsuite     14
  internal compiler error       4 (2 errors, 2 subsequent failures)
  probably real failure         2
# of unexpected successes       1
# of expected failures          66
# of unresolved testcases       28
# of unsupported tests          133

For complete report see:
http://www.penguin.cz/~utx/zaurus/temp/testsuite/

I may re-run tests for armv5 to see whether there is any regression for
iwmmxt.

> > The last missing thing - iwmmxt support in qemu - was already written by
> > Andrzej Zaborowski.
> 
> Is this "qemu-pxa270-and-more.patch" or is there something newer?  Has
> this been put into OE's buildtree?

It should be. But it seems, that in latest qemu-0.9.1, these patches are
present, but iwmmxt files are not compiled.

> NB, Not sure what you're using to profile the speedups, but there is:

I did not yet tried to profile the code. I only did measurements of
decoding time of video by MPlayer.


________________________________________________________________________

Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: iwmmxt optimization on PXA270 (dejagnu test report)

[Hasjim Williams]

On Sun, 23 Mar 2008 19:01:33 +0100, "Stanislav Brabec" <utx@penguin.cz>
said:

> I tested gcc-4.2.2-r6 with -march=iwmmxt -mcpu=iwmmxt -mtune=iwmmxt on
> my image compiled for iwmmxt.
> 
> Results seems to be promising. 99.99% tests passed. Results for Fortran
> are invalid (I had not libgfortran in the system). Surprisingly, all
> g++.dg/eh (exception handling) tests PASSed.

I was a bit surprised that all the exception handling tests PASSed, but
then I realised that there is no code to test exceptions on iwmmxt in
that directory:

tmp/work/ep9312-angstrom-linux-gnueabi/gcc-cross-4.2.2-r6/gcc-4.2.6/gcc/testsuite/g++.dg/eh/

The only unwind tester is arm-vfp-unwind.C , which is for the VFP
coprocessor and floats, doubles, etc on VFP.

iwmmxt should make use of uint64 / uint32, and simd .  I think simd-1 &
simd-2 are only run for x86 machines with MMX.  We probably need
something similar to test the popping of iwmmx data/control registers.

I suspect we may need to write a quick test app to check for this error
/ testcase...

The other reason why some iwmmxt compiled apps are segfaulting is that
something in iwmmxt support is missing.  Whilst the gcc testcases cover
most of the major tests, sometimes we need to add extra test cases for
100% test visibility.  I suspect that if gcc tries to do a
Unwind_VRS_Pop and get the NOT_IMPLEMENTED signal, it causes the
segfault.

Not sure if there are many extra bugs introduced by compiling for iwmmxt
vs armv5t, but I suspect this is the only "major" one.  It would be good
if someone has already done these tests (or arm/armv5), so we can do a
simple diff against the files to see what regression there is for
iwmmxt...

Re: iwmmxt optimization on PXA270 (dejagnu test report)

[Hasjim Williams]

On Wed, 26 Mar 2008 11:39:35 +1000, "Hasjim Williams"
<openembedded-devel@lists.futaris.org> said:
> 
> On Sun, 23 Mar 2008 19:01:33 +0100, "Stanislav Brabec" <utx@penguin.cz>
> said:
> 
> > I tested gcc-4.2.2-r6 with -march=iwmmxt -mcpu=iwmmxt -mtune=iwmmxt on
> > my image compiled for iwmmxt.
> > 
> > Results seems to be promising. 99.99% tests passed. Results for Fortran
> > are invalid (I had not libgfortran in the system). Surprisingly, all
> > g++.dg/eh (exception handling) tests PASSed.
> 
> I was a bit surprised that all the exception handling tests PASSed, but
> then I realised that there is no code to test exceptions on iwmmxt in
> that directory:

Joseph S Myers just replied to my post on the gcc mailing list, about
this:
http://www.nabble.com/Re%3A-wot-to-do-with-the-Maverick-Crunch-patches--p16397272.html

gcc 4.2.2 doesn't have the patch for iwmmxt unwind support applied:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00049.html

It should be in gcc 4.3.0.

binutils 2.18 should have this patch applied already:
http://sourceware.org/ml/binutils/2006-08/msg00207.html

binutils 2.17 doesn't have the patch applied.

Re: iwmmxt optimization on PXA270 (dejagnu test report)

[Hasjim Williams]

On Tue, 01 Apr 2008 10:27:24 +1000, "Hasjim Williams"
<openembedded-devel@lists.futaris.org> said:
> 
> Joseph S Myers just replied to my post on the gcc mailing list, about
> this:
> http://www.nabble.com/Re%3A-wot-to-do-with-the-Maverick-Crunch-patches--p16397272.html
> 
> gcc 4.2.2 doesn't have the patch for iwmmxt unwind support applied:
> http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00049.html
> 
> It should be in gcc 4.3.0.

We could also go to gcc 4.2.3, as I think the patch is in there.  Also,
gcc-4.2.4 is supposed to be released soon.