Created a Google docs spreadsheet to help visualise the benchmark
results. The graphs are not very informative yet - too many lines and
too much noise. I'm going to have to revisit them.
Continued trying to build Android. The toolchains build fine, but
Android itself complains about -Werror, and there are a few other real
errors too. Considering I was told it built fine with GCC 4.6 and all I
needed to do was tweak 4.5 to match, I'm not terribly impressed. I'm
sinking too much time into fixing up Android, and I haven't even got to
looking at the compiler trouble. Alexander Sack has said he will try to
get me to a more appropriate starting place (I think), so I'll see what
happens there.
Discussed my maddhidi4 patch with Richard E (wearing his GCC ARM
maintainer hat). He's not convinced that my change won't make something
else produce worse code. I can't prove that it won't either, so I'm
going to have to revisit it.
Wrote up the GCC 4.6 branch policy and upgrade plan.
Just a reminder that the dial-in numbers for today's and all future
calls has changed. See:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings
for the new list. I'll hang out on IRC just before the meeting to
help the lost...
-- Michael
RAG:
Red:
Amber:
Green: qemu-linaro RC0 prerelease uploaded
Current Milestones:
| Planned | Estimate | Actual |
first qemu-linaro release | 2011-01-11 | 2011-01-11 | |
Historical Milestones:
finish virtio-system | 2010-08-27 | postponed | |
finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 |
successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 |
finish qemu-cont-integration | 2010-01-25 | 2010-01-25 | handed off |
* maintain-beagle-models:
+ went through diffs between qemu-linaro and qemu-meego to
confirm we hadn't dropped any patches by mistake
+ tested qemu-linaro tree on ubuntu netbook image: boots OK
+ investigated and fixed qemu bugs caused by new x-loader
https://bugs.launchpad.net/qemu-linaro/+bug/704484
and new u-boot:
https://bugs.launchpad.net/qemu-linaro/+bug/703094
+ made merge requests to meego for a CRIS compile failure
and the x-loader bugfix
http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/4http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/5
+ Went through the process of doing a qemu-linaro release
with a "RC0" prerelease as a pipecleaning exercise and
to provide a tarball to slangasek for doing packaging. Download:
https://launchpad.net/qemu-linaro/+milestone/2011.02
Release process writeup:
https://wiki.linaro.org/WorkingGroups/ToolChain/QemuReleaseProcess
* merge-correctness-fixes
+ the usual upstream mailing list monitoring and code review
+ tested and sent meego VQ(R)DMULH.s16 fix upstream:
http://patchwork.ozlabs.org/patch/80725/
+ working on a patch to fix decoding of the preload and hint space
Current qemu patch status is tracked here:
https://wiki.linaro.org/PeterMaydell/QemuPatchStatus
Absences:
17/18 March: QEMU Users Forum, Grenoble
Holiday: 22 Apr - 2 May
SPEC
Tried to track down what was going on with lbm; it doesn't seem to
be repeatable on canis1; I'd previously seen it fail at O1 and work at
O0 and tried to chop down the flags between the two; but after adding
all the flags back in on top of -O0 it still worked and then I tried
-O1 again and it worked. Going to try on another machine, but it
might be uninitialised data somewhere.
Panda
Our panda arrived; it's now happily nestling near our Beagles and
running the 0126 headless snapshot (with 0127 hwpack). It seems fine
except
for rather slow USB and SD IO. Tip: Panda's do absolutely nothing (no
LEDs, no serial console activity) unless you put an SD card
in with the firmware on.
Libffi
Wrote the changes for armhf. Tested on arm, armhf, i386, ppc and
s390x - all happy. (Not too unsuspectingly variadic calls just work
on everything other than armhf without the api change)
Mailed Python CType list asking how much of a pain the API change
will be and any hints on what might be affected.
Awaiting sign off for submission of code.
Optimised library routines
Looked at benchmarking 'git'; I'd seen previous discussions where it
had been pointed out that it spends a lot of time in library routines;
and indeed it does spend useful
amounts in memchr, memcpy and friends on a simple git diff v2.6.36
v.2.6.37 > /dev/null of the current kernel tree produces a useful
~25second run.
One interesting observation is that the variation in the times
reported by 'time' - i.e. user, system and real, the variation in
user+system is much less than either user or
system individually and is quite stable (within ~0.7% over 10 runs).
I've just tried preloading my memchr routine in and it does get a
consistent 1-1.2% improvement which does look above the nice.
Also asked on libc-help list for suggestions as to other benchmarks
people actually trust to reflect useful performance increases in core
routines as opposed to totally
artificial ones.
Dave
== GCC ==
* Determined root cause of #Bug 598462 (corrupted profile info
with -O[23] -fprofile-use), identified work-around (using
-fprofile-correction), and verified on GCC 4.5 and 4.6
== GDB ==
* Worked on re-implementation of fix for #615978 (Failure to
software single-step into signal handler)
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
== GCC ==
* Internal ARM tasks that kept me busy for some time this week.
* Reworked the divmodsi4 patch based on comments. Still some test
failures that need to be investigated.
* Started working on the performance improvement plan for GCC 4.5.
* Number of patch reviews upstream.
* Looking at A9 memset issue. .
* Got an internal bug report about the 4.4 tools from someone using it
which had to do with a missing backport. This is now lp:709329.
Backported and testing.
* Backported a missing upstream patch into GCC 4.5 for bswap patterns.
* Wrote up on how to cross-test with qemu and updated that on the
Linaro wiki. Comments are welcome.
Plans:
* Find out the default number of iterations needed for steady state
with EEMBC.
* Finish testing fix for lp:709329 and get that committed.
* Finish off divmodsi4 patch and get it's testing completed and
finished.
* Submit backport for bswapsi at Os fix (PR44392) for gcc-linaro
* Finish the plan for GCC performance improvements based on what we
discussed at the
sprint.
* Away 2-1/2 days next week for an internal engineering conference.
This week
=========
- On other IBM duties until today. Now finished!
- Looked at the neon failures that Peter reported. I'm testing patches
for the ICE and the "must be a constant" error now.
- In the background, I've been trying to pin down the chromium build
failure. I can only reproduce it when running under dpkg-buildpackage:
if I run the link line manually, it works. This is reminiscent of a
problem that Dave saw elsewhere: the linker segfaulted only when run
through the normal build system.
Next week
=========
- Bernd Schmidt has committed our combined patch for #695302.
Will backport to our sources.
- Submit the neon fixes above.
- More on STT_GNU_IFUNC. There are some more tests I want to write.
Richard
Some news from the qemu mailing list that I think might be
of interest to gcc folks here:
Christophe Lyon from ST has kindly released a large
set of test cases of Neon intrinsics:
http://gitorious.org/arm-neon-tests/arm-neon-tests
(the tests themselves are more aimed at testing qemu,
so they just produce output to be compared against a
reference generated from running on hardware).
However they don't currently compile with gcc (but
are ok with armcc). From the README:
# The tests currently fail to build with GCC/ARM:
# - no support for Neon_Overflow/fpsrc register
# - ICE when compiling ref_vldX.c, ref_vldX_lane.c, ref_vstX_lane.c
# - fails to compile vst1_lane.c
# - missing include files: dspfns.h, armdsp.h
Maybe it's worth somebody having a look at this,
at least enough to find out whether the ICEs are
things we already know about or have perhaps
already fixed in linaro gcc?
thanks
-- PMM
Hi,
I am working on implementation of interleave_high/low and
extract_even/odd for NEON. The pairs of high/low (even/odd) are
"magically" united into single vzip (vuzp) instruction in the back
end, so there is no need in special support from the tree level. There
are still some test failures that I need to solve.
Ira
