Summary:
* arm-linux-gnueabihf and multilib support for linaro toolchain.
* Code size benchmark analysis.
Details:
1. arm-linux-gnueabihf support for linaro toolchain
* Update gcc, libgcc and libstdc++ config to support the triplet.
* Update build scripts to gnueabihf.
* Add sample config for gnueabihf.
2. Multilib support for linaro toolchain
* Merge Terry's multilib patches
(http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00975.htmlhttp://gcc.gnu.org/ml/gcc-patches/2012-05/msg00083.html) and revise
them for linaro.
* Update gcc.c and incpath.c to make multiarch and multilib work together.
* libgcc for armv4t (-mfloat-abi=soft) build fail: ld: error:
armv4t/libgcc_s.so.1.tmp uses VFP register arguments, ... does not.
Root cause: crt*.o from precise sysroot use VFP_args, while other
objects are built with -mfloat-abi=soft. We need additional crt*.o to
build libgcc for armv4t.
3. Code size regression analysis
We find more regression cases introduced by ivopt and loop invariant.
Plans:
* Investigate other code size regressions in 4.7.
* Finalize the arm-linux-gnueabihf and multilib support for linaro toolchain.
Best regards!
-Zhenqiang
I've lost track of the benchmark builds so I've started a manual todo list at:
https://wiki.linaro.org/MichaelHope/Sandbox/Todo
It's been messy with the validation lab being down and some builds
being in my home office and some in Cambridge. Let me know if I'm
missing any.
-- Michael
Hi folks,
We really need to push on with getting the loader path for armhf
standardised. The path that was agreed months ago is
/lib/arm-linux-gnueabihf/ld-linux.so.3
but clearly not everybody is using that yet. Dann has just posted an
updated patch for gcc, and we want to get this reviewed / fixed up /
accepted ASAP. Then we may need to backport it to older gcc releases.
This is *important* so that we can help vendors release binaries that
work on any hard-float distribution. For people who have made binaries
that still use the old, broken location /lib/ld-linux.so.3, we can put
symlinks in place *for now* but in the longer term as many distros
switch to multi-arch the symlink is not an acceptable solution.
I'm working on a more complete spec document for armhf to help us with
this kind of thing, but it's not going as smoothly as I'd hoped and I
don't want to wait for that as a blocker on the linker path.
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-06-23 || ||
Historical Milestones:
||initial-a15-system-model || 2012-01-27 || 2012-01-27 || 2012-01-17 ||
||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04 || 2012-02-01 ||
== other ==
* cleaned up and refactored QEMU GIC/NVIC code enough to provide
a solid foundation for the in-kernel irqchip support. Posted
the refactoring bits to qemu-devel. This should be enough to
unblock Marc Z.
* qemu-linaro: LP:978694: added patch from Peter Chubb fixing
beagle bootrom FAT12/FAT16 handling
* finished a trivial bit of cleanup of an omap3 ID register patch
I'd had lying around half-done for a while
* investigating a bug reported by Alex Graf where we get a segfault
gtk-query-immodules-2.0 but only if qemu's 'reserve memory space'
feature is being used: this appears to be an interestingly nasty
case where if the guest does mmap(dll); execute code in dll;
munmap(); mmap(dll 2); execute code in dll 2; and the two mmap()s
happened to pick the same address then we will end up using a
stale cached translation from dll 1 when executing dll 2...
-- PMM
== GCC ==
* Completed testing and benchmarking of patch to use vld1/vstd1
instead of vldm/vstdm for vector moves. Saw no regressions but
only minor benefits.
* Checked in patch to fix LP #959242 (GCC PR tree-optimization/52633)
to FSF mainline and 4.7 branch; backports to Linaro GCC 4.7 and 4.6
pending.
* Checked in mainline patch to enable -fsched-pressure by default
on s390.
* Ongoing work on improving end-of-loop value computation.
* Started investigation of TSVC vectorizer test kernels.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Hi Uli,
While looking into something else I ran into these - I wonder how many
of these GCC manages to vectorize ...
http://www.netlib.org/benchmark/livermorec . These look interesting
from a vectorizer kernels point of view.
The other interesting paper of note was this PACT paper on
vectorization benchmarks comparing icc , xlc and GCC which might
provide some interesting hints / reading.
http://polaris.cs.uiuc.edu/~garzaran/doc/pact11.pdf . The appropriate
benchmarks kernels are linked to below.
http://polaris.cs.uiuc.edu/ ̃maleki1/TSVC.tar.gz.
regards,
Ramana
I've put the agenda for Monday's call at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2012-05-07
which is:
* Review action items from last meeting
* Connect sessions:
* GDB for Android
* GCC performance call - Live!
* KVM performance
* Renderscript
* Android benchmarking
* Dalvik improvements
* Hard float switchover status
* multiarch upstreaming
* Next week is release week
* vld1, EEMBC results, and noise
* twolf result variance
* KVM minimum features
* UP/UP, Ubuntu
* [[MichaelHope/Sandbox/KVMUseCase]]
Feel free to edit,
-- Michael
I've done some minor updates to the instructions for working with
gcc-linaro, bzr, and merge requests at:
https://wiki.linaro.org/WorkingGroups/ToolChain/BzrTips
The interesting changes are using:
* bzr commit --fixes=lp:nnnn to link a branch to a bug number
* bzr branch --hardlink to cut down on branch time and disk usage
* bzr-merge-changelog to automatically merge ChangeLog.linaro
-- Michael
