Hi,
* continued to work on getting libunwind support for remote unwinding
upstream
* reworked some of the code to address concerns from the ml
* now upstream!
* made smaller fixes to have another libunwind testcase passing
* interfaced with the Linaro Android group to solve an issue where a
compile was failing when using -O3
* turned out that the Linaro GCC vectorizes a loop by generating some
neon instructions
* unfortunately the gas of the 2.20.1 binutils (that is currently
used by the Linaro Android toolchain) doesn't properly understand the
alignment restrictions of the generated asm code and throws an error
* this has be fixed upstream and using a gas from recent binutils
fixes the issue
* Bernhard is already working on getting newer binutils in their
Androuid toolchain build system
* continued the work to get libunwind building on Linaro Android
* wrote an Android.mk and got an initial libunwind.so built (ugly
hacks involved)
* next step is modify the debuggerd to make use of libunwind.so
Note: Next week I'll be on vacation.
Regards
Ken
== This week ==
* Looked at LP #823711. Turned out to be a problem with symbol
visibility in libgcc.a. Tested a fix that was accepted and applied
upstream. Will backport to upstream release branches, so we should
be able to pull the fix in that way.
* Backported the fix for BZ PR49987 to Linaro 4.6 and 4.5.
* Looked at the regrename bug that Ramana reported on gcc@.
* Looked at why libav wasn't being vectorised. Discussed with Ira.
I think we now have a Plan.
* Submitted address writeback scheduling patches upstream.
* Submitted and applied some tweaks to the rtx cost interface upstream.
* Spent a while trying to figure out what the targetm.rtx_costs
API actually is, and how rtx_cost should use it to evaluate the
cost of a SET. Discussed on gcc@.
* Found that ARM was giving SETs a base cost of 4 instructions.
Benchmarked the cost of "fixing" this. It generally seemed positive.
* Wrote a couple of other rtx cost patches.
== Next week ==
* Backport fix for #823711 to upstream branches.
* Hopefully finish off rtx costs stuff.
* Unless there's a clear outcome from the gcc@ discussion, I think
I'll abandon my idea of using insn_rtx_cost in the new auto inc/dec
patch, and simply sum the cost of every SET. Should be a small change.
Richard
* Started running EEMBC on Panda. Got three errors in the automotive test at
this point.
* Started documenting necessary steps for my start-up task:
https://wiki.linaro.org/Internal/ToolChain/Benchmarks/First%20time%20notes
* Upgraded the Snowball board to the latest version (V3). Created a
corresponding test image for Snowball (Linaro 11.06). There is a problem
with the serial console freezing after a couple of minutes without any
error, not sure if it is a complete crash or just the serial output. The
people I have talked to so far has not experienced the same problem. I will
set up the networking for the board and see where ssh gets me.
Best Regards
Åsa
Hi,
- change of default vector size for auto-vectorization on NEON -
submitted and approved
- continued working on vectorization of widening shifts
- looked into SLP vectorization for libav
- two vacation days
I'll be on vacation on Aug 22-30.
Ira
I put a build harness around libav and gathered some profiling data. See:
bzr branch lp:~linaro-toolchain-dev/+junk/libav-suite
It includes a Makefile that builds a C only, h.264 only decoder and
two Creative Commons licensed videos to use as input.
README.rst has the basic commands for running ffmpeg and initial perf
results showing the hot functions. Dave, 20 % of the time is spent in
memcpy() so you might want to have a look.
The vectoriser has no effect. GCC 4.5 is ~17 % faster than 4.6. I'll
look into extracting and harnessing the functions themselves later
this week.
-- Michael
Hi,
is the Linaro toolchain (esp. gcc) useful on x86/x86_64, or is an
attempt to use the Linaro toolchain with such a target just asking for
trouble?
(No, I'm not secretly an Intel spy ;) Just trying to have some fun
with my desktop machine ;) )
ttyl
bero
The Linaro Toolchain Working Group is pleased to announce the release
of Linaro GDB 7.3.
Linaro GDB 7.3 2011.08 is the first release in the 7.3 series. Based
off the latest GDB 7.3, it includes a number of ARM-focused bug fixes.
This release includes all bug fixes from the latest Linaro GDB 7.2
release that were not already included in FSF GDB 7.3.
In addition, this release fixes:
* LP: #804401 [remote testsuite] Thread support
* LP: #804387 [remote testsuite] Shared library test problems
* LP: #804392 [remote testsuite] Rebuilt executables not copied
* LP: #804396 [remote testsuite] Spurious failures
The source tarball is available at:
https://launchpad.net/gdb-linaro/+milestone/7.3-2011.08
More information on Linaro GDB is available at:
https://launchpad.net/gdb-linaro
The Linaro Toolchain Working Group is pleased to announce the release
of Linaro QEMU 2011.08.
Linaro QEMU 2011.08 is the latest monthly release of qemu-linaro. Based
off upstream (trunk) QEMU, it includes a number of ARM-focused bug fixes
and enhancements.
This month's release is primarily minor improvements:
- Fixes LP:816791: ARMv6 cp15 barrier instructions now work
in linux-user mode as well as system mode
- Support for ARM1176JZF-S core has been added (thanks to
Jamie Iles <jamie(a)jamieiles.com>)
- Add workaround for kernel bug LP:727781 (which has resurfaced
in 3.0) to suppress warnings about bad-width omap i2c accesses
Plus of course new upstream fixes and improvements.
Performance:
When running qemu in system mode with an SD card image we have
determined that performance is best when the image is in writeback
caching mode. This significantly increases the performance of the SD
card (by factors of 10 or more). An example command line option is:
-drive if=sd,cache=writeback,file=my-sd-card.img
Note that cache=writeback may result in data not being written to
disk if the host system powers down unexpectedly (guest crashes
or powerdowns are not a problem).
Known issues:
- The beagle and beaglexm models still do not support USB networking
- There may be some problems with running multithreaded programs in
linux-user mode (LP:823902)
The source tarball is available at:
https://launchpad.net/qemu-linaro/+milestone/2011.08
Binary builds of this qemu-linaro release are being prepared and
will be available shortly for users of Ubuntu. Packages will be in
the linaro-maintainers tools ppa:
https://launchpad.net/~linaro-maintainers/+archive/tools/
More information on Linaro QEMU is available at:
https://launchpad.net/qemu-linaro
The Linaro Toolchain Working Group is pleased to announce the 2011.08
release of both Linaro GCC 4.6 and Linaro GCC 4.5.
Linaro GCC 4.6 2011.08 is the sixth release in the 4.6 series. Based
off the latest GCC 4.6.1+svn177703, it focuses on fixing bugs found
during the Android integration and in SMS. This is a quiet release
due to Linaro Connect.
Interesting changes include:
* Updates to 4.6.1+r177703
Fixes:
* LP: #736007 ICE immed_double_const at emit-rtl.c
* LP: #809768 ICE when compiling bionic's libm
* LP: #815777 Inconsistent packaging between tarball and root
directory names
Linaro GCC 4.5 2011.08 is the thirteenth release in the 4.5
series. Based off the latest GCC 4.5.3+svn177552, the release is
focused on maintenance.
Interesting changes in 4.5 include:
* Updates to 4.5.3+r177552
* Now builds for PowerPC
Fixes:
* LP: #736007 ICE immed_double_const at emit-rtl.c
* LP: #809768 ICE when compiling bionic's libm
* LP: #815435 ICE: insn does not satisfy its constraints
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.6-2011.08https://launchpad.net/gcc-linaro/+milestone/4.5-2011.08
Downloads are available from the Linaro GCC page on Launchpad:
https://launchpad.net/gcc-linaro
Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Bugs: https://bugs.launchpad.net/gcc-linaro/
Questions? https://ask.linaro.org/
Interested in commercial support? inquire at support(a)linaro.org
-- Michael
On Thu, Aug 18, 2011 at 4:16 AM, Richard Earnshaw
<Richard.Earnshaw(a)arm.com> wrote:
> I was just browsing libgmp this afternoon and noticed that it really
> could do with an overhaul to support recent ARM chips.
>
> The ARM code seems to have been written for StrongARM; which is now
> almost obsolete (for example, it loads from a cache line it is about to
> write to in order to pre-allocate the line in the cache).
>
> It doesn't support v4T interworking.
>
> It doesn't make any use of v5 or later instructions.
>
> There is some Thumb(1) code, but again it has no support for
> interworking, is pretty poor and limited in scope.
>
> I'm not sure overall how useful this is to gcc performance; the library
> is needed to build GCC, but I think it's mostly there to support libmpfr.
>
> Nevertheless, there are other apps out there that make use of this
> stuff, including some crypto code, IIRC.
I looked at using gmp as a benchmark some time ago. The assembly
version is twice as fast as the C version already, which is nice. I
assume NEON would be a big improvement as well.
I had a quick poke through the dependencies in Ubuntu and came up with
the following popular packages that use libgmp or libmpfr:
* guile
* python-crypto
* gch (Haskel)
* maxima
* darcs
Nothing earth shattering but probably worthwhile. I've registered:
https://blueprints.launchpad.net/linaro-toolchain-misc/+spec/improve-libgmp
so that we don't lose it.
-- Michael
