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
Hi,
I've written up a wiki page finally on the cross-testing with qemu
here. It's taken me slightly longer than expected as I was playing
around with moin-moin syntax. These are based on qemu-0.13.0 which is
what I tried when I wrote this up for some testing of a patch that I
was playing with.
https://wiki.linaro.org/WorkingGroups/ToolChain/CrossTestingQemu
Comments are welcome .
Ramana
Hi,
* I looked into the perf utility with regard to ARMv7 and raw event support
* https://wiki.linaro.org/KenWerner/Sandbox/perf
* testsuite fixes for the OpenCL GDB
* started to setup the pandaboard (currently the headless snapshot hangs
shortly after I got the bash prompt - I'm not sure what's going on here)
* On Friday I'll attend a class.
Regards
Ken
Hello,
* Submitted to mainline the patch to model Doloop for ARM
(http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html) .
The ARM back-end part was reviews by Richard Earnshaw.
* Looking into EEMBC/DENbench for opportunities applying Modulo-Scheduling.
Based on partial profiling information there are SMSed hot loops. My next
step is to generate complete profiling information (including gcov info)
and execute the benchmarks on ARM machine.
Thanks,
Revital
Hi Vijay,
On Sat, Jan 22, 2011 at 9:59 AM, Vijay Kilari <vijay.kilari(a)gmail.com> wrote:
> Hello Dave,
>
> Thanks for this info.
>
> I have few more queries after looking at the results of memset on A9 & A8.
> I agree that externel bus speed matters in comparision across platforms.
>
> 1) Why memset is performance is good on A8 than A9?. any justification?
I've CC'd the linaro-toolchain list who have been working on this
topic and may be able to provide you with more information.
Cheers
---Dave
