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
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
Hi there. I've had a think and done a write-up on the causes behind
the 2011.01 release failure and what should be changed. See:
https://wiki.linaro.org/WorkingGroups/ToolChain/Incidents/2011.01-X86_64
The changes involve being more explicit in the release process
document and changing the continuous build to give earlier warning.
Comments are appreciated.
-- Michael
Hello,
I have a patch for ARM that I want to test and I'm not sure what's the
procedure of testing in Linaro nor to where
it should be committed. (GCC trunk? it's currently under bug fixes mode
only).
I appreciate help with that.
Thanks,
Revital
Hello,
could you please provide some comments about the state of "-Os"
(optimising for size) in the gcc 4.5.x versions of Linaro's tool
chain?
It appears there are a number of issues with recent versions of GCC
that get triggered when optimising for size, for example
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45052http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392
Some other projects like the Linux Foundation driven Poky (resp.
Yocto project) capitulated and stopped using -Os, see for example
here:
http://thread.gmane.org/gmane.linux.embedded.poky/2311/focus=2565
On the other hand, I can see that Linaro even adds improvements for
"-Os", see for example here:
http://thread.gmane.org/gmane.linux.linaro.toolchain/367
So I wonder what the state of these problems with "-Os" is in the
Linaro tool chain? Have these issues been solved, and is "-Os"
reliably working with the Linaro tool chain?
Thanks in advance.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de
The optimum committee has no members.
- Norman Augustine
I assume we're moving the toolchain calls over to the
new confcall numbers -- but just to check, are we doing
so for this Wednesday's status call? The calendar
entry still has the old numbers...
-- PMM
==GCC==
Progress:
* Got invited to the Toolchain WG and was at the sprint in Dallas.
* Worked on fixing inconsistencies in the A9 scheduler. Now fixed up
upstream and submitted merge request for that.
* Introduced to other members of the Toolchain WG and had
conversations with everyone about what was going on within the
Toolchain WG.
* Spent some time trying to set up a Pandaboard that I borrowed
(Thanks Wookey) but the Panda didn't work. Turns out both the SD cards
were broken and or the versions of the boot loader / firmware were
broken.
* Worked through the patch list with Andrew trying to understand the
patches that exist in the backend for the delta between gcc-linaro and
upstream.
* Did some patch review upstream to help ease the backlog.
* Flushed some patches out from my patch queue upstream.
* Fixed the scheduler issue upstream and submitted a merge request for
it in linaro gcc-4.5 since it really fixes the A9 scheduler.
* Some ARM internal tasks with respect to transition into Linaro.
* Worked on the divmodsi4 issue and testing my patch with trunk.
Pushed my branch into launchpad if someone wants to see the code. Does
the right thing for the case we want but won't help with the SPEC2k
case really because that's a case with Os. But a good size improvement
anyhow and something that will help with divmod cases with 2 variables
rather than where a constant is used.
* Set up a natty chroot on one of our ve2 boxes which is now running a
bootstrap for all languages we are interested in and collecting test
results from trunk upstream.
* Worked through the new starter guide and still have an issue with
accessing wiki.linaro.org
Absences:
February 1-3:ARM Internal engineering conference.
== GCC ==
* Analyzed root cause of #685352 (libplymouth2_0.8.2-2ubuntu6 and
later give ragged splash and text rendering), opened mainline
bugzilla PR rtl-optimization/47299
* Submitted backport merge request for the #685352 fix
* Successfully completed profiled-bootstrap run on ARM
* Investigated profiled pyhton package build problems
== GDB ==
* Forward-ported GDB patch to support ARM hardware watchpoints
* Determined root cause of #615978 (Failure to software single-step
into signal handler), started discussion of proposed fix
* Miscellaneous Launchpad bug maintenance
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
=A9 Qemu=
I've spent most of the week looking at QEmu emulation of SMP A9. The
model (of a realview-pbx-a9) doesn't have any working block IO;
I spent some time looking at trying to get SD working and got part
way, but I fell back to using NFS root.
It seems to work OK for basic CPU emulation, and SMP 'works' in the
sense that the guest sees multiple CPUs;
however QEmu is restricted to only using one host CPU core for
multiple guest CPUs, so it's of limited
help in debugging SMP code.
Video doesn't seem to work either.
To get to that point it does need a bunch of patches to QEmu, most of
which Peter Maydell already knows of;
I've put some notes here :
https://wiki.linaro.org/Internal/People/DaveGilbert/QEMUA9SMP
Note that the realview-pbx doesn't currently have a Linaro hardware
pack; I used a kernel from ARMs website
and a 2.6.37 I built myself.
=SPEC=
SPEC ref got quite a far way through on Canis (with half-duplex
ether), however 'lbm' failed when running
in ref mode (while having worked in test and train) giving a different
output; it takes quite a long time to fail.
= Perf =
I sent an updated version of my patch for perf's thumb annotation upstream.
and apparently we have a Panda on the way.
Dave
RAG:
Red:
Amber:
Green:
Current Milestones:
| Planned | Estimate | Actual |
finish qemu-cont-integration | 2010-01-25 | 2010-01-25 | handed off |
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 |
* submitted meego patch upstream to print instruction
boundaries in TCG op-level debug dumps:
http://patchwork.ozlabs.org/patch/79298/
* reviewed a couple of patches by Christophe Lyon from ST
which fix some problems with VMULL and friends
(together with a qemu-meego patch in the same area)
* lots of rebasing work to get a qemu-linaro tree into
shape. Mostly putting together my exploded set of
ARM patches from the meego tree with a rebased set
of omap patches. I have something which I think is about
right but I need to test it.
* patches submitted to qemu upstream:
+ add -version option to qemu-user:
http://patchwork.ozlabs.org/patch/79635/
+ fix writing default vector address in PL190:
http://patchwork.ozlabs.org/patch/79712/
+ print instruction boundaries in TCG op-level debug dumps:
http://patchwork.ozlabs.org/patch/79298/
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
I had a few spare cycles this afternoon on my A9 board so I got it to
build and run 72 variants of CoreMark with the 2011.01 compiler. The
results are here:
https://wiki.linaro.org/MichaelHope/Sandbox/CoreMark1
I haven't looked deeply into it and the usual disclaimer about
benchmarks applies, but there's some interesting stuff there. The ARM
to Thumb-2 drop is more than expected. Tuning for Cortex-A9 generally
makes things worse.
-- Michael
Hi,
One of the things that came up in yesterday's chat was about ARM vs
Thumb2. If some folks are interested in a high level overview that
doesn't go into too many details with respect to the ISA that I know a
compiler writer will be interested in you could read this presentation
unless you've seen it. At the minute the canonical way of figuring out
more about Thumb2 is really to read the ARM-ARM.
https://wiki.ubuntu.com/Specs/M/ARMGeneralArchitectureOverview?action=Attac…
This was a presentation that Dave Rusling gave at the UDS in Belgium
last year, it roughly covers the architecture at a high level and
talks about Thumb2 vs ARM , why Thumb2 , the evolution of the ARM
architecture etc. It's not a lot of detail but quite a high level overview.
HTH
cheers
Ramana
Hi,
* finished SLP for reduction patch. The loop in DenBench that needs
this feature also requires support of load permutation. I am
considering to implement that too. I looked for other occasions that
need this feature, but only found loops that are not vectorizable. So,
I am not sure I'll proceed in this direction.
* looked into extract_even/odd and interleave_high/low implementation
on ARM as a backup plan for the case we don't have special load/store
support on time for the next release. Even though NEON VZIP and VUZP
instructions can perform both even and odd (and high and low)
computations simultaneously, I don't see how we can express that at
the tree level.
* looking into ffmpeg
* non-Linaro issues
Ira
Hi ,
So rather than manually backporting a patch from upstream "trunk" I
decided to try using bzr for this yesterday. Even though this was a
slow process and thanks to some help from Michael on IRC last night I
think I got it right finally. However I can't get bzr visualize to
show me the revision history correctly with the merge from the
upstream repository.
So what I did was to do the following
bzr branch 4.5 new-branch
cd new-branch
bzr merge -c XXX lp:gcc where XXX is the bzr revision number of the
svn commit that I'm tracking upstream.
gcc/Changelog merge fails - there is a conflict. Expected because you
are merging trunk's gcc/Changelog into a version of the Changelog file
in our tree
Thus I reverted changes that were brought in by copying in a backup of
gcc/Changelog that I had made before the merge
bzr resolved gcc/Changelog
edit Changelog.linaro
Add changelog entry
bzr commit
bzr push lp:gcc private repository
Create merge request upstream.
Does this look sensible to people or do folks follow other recipes?
cheers
Ramana
