== GCC ==
* Committed fix for LP #960283 (PR tree-optimization/52686) to
FSF mainline as well as Linaro GCC 4.6 and 4.7.
* Worked on patch to use vld1.64/vst1.64 instead of vldm/vstm
for vector moves. Created merge request for testing.
* Worked on patch to use vld1/vst1 to implement vec_set/vec_extract
for cases where the scalar operand resides in memory.
Created merge request for testing.
* Ongoing work on fixing LP #959242.
* Ongoing work on improving end-of-loop value computation.
== Misc ==
* I'll be attending the Linux Foundation Collaboration Summit
in San Francisco next week, and present on "GDB on ARM".
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
Summary:
* Linaro binary toolchain 2012.03 release.
* Investigate relocatable NLS support.
* Code size benchmark analysis.
Details:
1. Linaro binary toolchain 2012.03 release.
* Bump and spawn 2012.02-20120326 build.
* Validate the release candidate.
* Update wiki for binary build tasks.
2. Investigate relocatable NLS support: lp:918926.
* Root cause: gcc and binutils use a fixed LOCALEDIR (which is
$prefix/share/locale) to call bindtextdomain.
* Workout a reference patch for gcc to use relative dir
(.../bin/../share/locale) to call bindtextdomain.
3. Code size benchmark analysis with -Os
* Collect code size benchmark data.
* In most cases, gcc 4.7 gets better result than gcc 4.6.
* Investigate regression in several small cases.
4. Read the tree and rtl dump files to learn the optimizations and
impacts on code size.
Plans:
* Fix lp:918926.
* Investigate code size regression in gcc 4.7.
* Tuning optimization heuristics for -Os.
Planed leaves:
* April 2 - 4: Chinese Qingming Festival.
* April 9 - 11: Vacations
Best regards!
-Zhenqiang
=== Progress ===
* Caught up on email backlog.
* Reworked the ARM backend specific bits of the VFP addressing modes
patch and submitted again for some benchmarking and testing. Finished
the PRE_MODIFY and POST_MODIFY bits of that as well.
* Wrote up a small blueprint on the shrink-wrapping work.
* Wrote up my Linaro performance review and sent it for review.
* Looked at lower-subreg work that Kenneth Zadeck posted very quickly
to see if it addressed some of the issues around and old intrinsics
patch that Richard Sandiford submitted last year. It looks promising
and might even have some impact on our 64 bit neon work . It fixes the
2 cases where things didn't look good. ( Upstream bug reports PR48941
and PR51980) but it falls over while building glibc. Sent a bug report
to Kenneth about this.
* The perf packages on OMAP4 in our latest releases from 12.03 are
just broken, they don't work. Reported the issue to Paul Larson on IRC
to check what's going on. perf top doesn't work reliably on the
kernels and there appears to be some issues with interrupt support for
some of these . I specifically ran into
https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/956693 .
* Answered a few questions from Uli about my prototypes for the vld1
replacing vldm instructions and a vget_lane patch.
== Plans ==
* Work through some of the blueprints before the call next week.
* Set up perf on my panda. It works on my AC100 - so the inclination
was to also have something that worked on my panda but clearly it
doesn't.
* Finish off the VFP addressing modes patch and get it in.
* Look at Partial Partial PRE next or attempt the next project.
Absences.
* Apr 12-13 : Euro-LLVM London.
* 1 week holiday sometime before that - to be booked
* Linaro Connect Q2.12 - May 28 - June 1 - travel booked - hotel to be booked.
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-04-10 || ||
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 ||
== cp15-rework ==
* posted 14-patch patchset which creates a QOM class per CPU type
and moves a lot of the reset/constant-feature-register setup to
the init functions for these new classes. This is then a much
nicer base to sit cp15 rework on.
* solved the final design knot of how to handle registers whose reset
value depends on the CPU type (the QOM patches make this much more
straightforward)
== other ==
* upstream patch review
* updated Paul Brook's BE8 userspace support patch and sent out a v2
* ran through qemu-linaro buglist identifying fixes to go into next
release
* linaro performance review ate up a lot of time this week and
will probably do so next week too :-(
I've changed the development focus in the Launchpad project to Linaro
GCC 4.7. This means that:
* Checking out lp:gcc-linaro now gives you the 4.7 branch
* New merge requests are targeted to 4.7 by default
This doesn't affect any already checked out branches or pending merge requests.
-- Michael
Hi,
GDB for Android:
* Wrote three patches for the build system allowing gdbserver
to be cross-compiled on Android [which were submitted upstream
this Monday].
* Started studying the ARM EABI to work on a way to mark a binary
as an Android application as opposed to a regular Linux EABI one.
* Wrote self-evaluation for Linaro performance review.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
The PandaBoard auto builders are having a hard time keeping with
longer build and test times of 4.7 and the re-enabled libstdc++ tests.
For reference, here's how much each step costs:
Bootstrap GCC with C, C++, Fortran, and Obj-C: 9 hours
Test GCC: 9.5 hours
Test libstdc++: 4.4 hours
Test libgomp: 0.9 hours
Other tests: 0.2 hours
for a grand total of 23.8 hours. Every new commit gives a merge
request and trunk build for both A9 and ARMv5 giving 95 hours of
compute time. GCC 4.6 takes five hours to build and 5.5 to test.
This is just a FYI. I'll think about ways of speeding things up or
adding capacity. An i.MX6 with 2 GB of RAM and SATA would be nice...
-- Michael
