RAG:
Red:
Amber:
Green: now only 6 "core ARM emulation" patches in qemu-linaro not
yet upstreamed (still lots of omap3 patches, though)
Current Milestones:
| Planned | Estimate | Actual |
qemu-linaro 2011-04 | 2011-04-21 | 2011-04-21 | |
Historical Milestones:
finish qemu-cont-integration | 2011-01-25 | 2011-01-25 | handed off |
first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 |
qemu-linaro 2011-03 | 2011-03-08 | 2011-03-08 | 2011-03-08 |
== maintain-beagle-models ==
* some early prep for next week's qemu-linaro release
== merge-correctness-fixes ==
* patch to fix Neon UNDEFs sent upstream and committed
* patch fixing an overflow in signed VABAL.s32 upstreamed, committed
* investigated a bug report which turns out to be that if you try
to single step over an instruction which UNDEFs using qemu's gdb
stub we execute the insn at the UNDEF vector and stop after it
rather than stopping at the UNDEF vector
* some investigation of qemu mishandling of FP exception flag setting;
putting this on hold though, as it really isn't very high priority
* reviewed patches from Aurelien doing some general softfloat cleanup
== other ==
* trying to nail down proposed QEMU work for next cycle;
work-in-progress: https://wiki.linaro.org/PeterMaydell/Qemu1111
* two IRC interviews for QEMU Google Summer of Code student to
do some work on upstreaming of the Android emulator device models
* meetings: toolchain, standup, architecture Q&A, divisional update
Current qemu patch status is tracked here:
https://wiki.linaro.org/PeterMaydell/QemuPatchStatus
Absences:
Holiday: 22 Apr - 2 May
9-13 May: UDS, Budapest
(maybe) 15-16 August: QEMU/KVM strand at LinuxCon NA, Vancouver
[LinuxCon proper follows on 17-19th]
Hi, I've just pushed a merge of the current upstream patches for
resolving the CoreMark regressions.
(https://code.launchpad.net/~cltang/gcc-linaro/coremark-part1)
To give a quick benchmark of the current status, testing Linaro 4.5
before/after the merge of those two patches:
Optimization options used were just plain '-O2 -mtune=cortex-a9', tested
on one of our Pandaboards running Maverick; all numbers are
Iterations/Sec averaged from 3 runs.
r99492 r9942+patches improve %
-march=armv5te 2786.87 2848.12 2.20 %
-march=armv7-a 2474.50 2775.92 12.18 %
-march=armv7-a -mthumb 2297.86 2356.59 2.56 %
I'll have to re-test to be sure, but the numbers/improvements obtained
using upstream trunk should not be too far off, at least the ARM mode ones.
As we discussed in prior meetings, there's still one point of regression
identified that's in solving, which hopefully will finally bring the
ARMv7-A numbers above ARMv5TE.
Chung-Lin
Hello,
- Tracking down bugs exposed while testing a patch for SMS to avoid
using -fauto-inc-dec flag and preparing fixes for them.
Also, prepared a fix for PR47013.
- Continue looking into DENbench and updating
https://wiki.linaro.org/Internal/ToolChain/Benchmarks.
Thanks,
Revital
== GCC ==
Progress:
* Spent some time digging into binutils issue for Neon but still not
sure why I see the problem when this is fixed in 2.21 branch and no one
else see this.
* Fixed PR 48090 upstream.
* Some patch review.
* T2 performance meeting.
Plans when I'm back:
* Continue looking at divmodsi4 improvements.
* Continue looking at excessive VFP moves.
* Backport the fix for the initialization of cgraph into FSF 4.5 branch.
Meetings:
* 1-1s
* Linaro toolchain meeting
* T2 performance.
* Linaro@UDS meeting.
Absences:
* April 15 – 26 -> Booked.
* May 9-14 - LDS Budapest
hey
This problem with busybox:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621137
seems to be a toolchain issue.
It occurs with FSF GCC 4.5.2 but not 4.6, and it doesn't occur with
Linaro GCC 4.5 but it does with Debian gcc-4.5. I'm trying to identify
the fix which Linaro applied to solve this! :-) Michael Hope told me
he remembers we fixed something similar for Qt, but he couldn't find
the patch and suggested I post here to get feedback.
I've pushed ash.i and .s at:
http://people.linaro.org/~lool/ash.i
which you can build with:
gcc -save-temps -std=gnu99 -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused -Wunused-parameter -Wunused-function -Wunused-value -Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement -Wold-style-definition -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections -fno-guess-branch-probability -funsigned-char -static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -g -Os -c -o ash2.o ash.i
the interesting part is that ash.s has tryexec as not returning, when
it does return:
grep ^tryexec ash.s -A5 | grep return
this seems to be due to the combination of tryexec being static, its
parent being noreturn, and one argument of tryexec being unused.
Any idea of which Linaro patch solved this? :-)
Does it make sense to raise this to FSF GCC 4.5?
Thanks!
--
Loïc Minier
Hi there. Mounir and I have been looking at the work for next cycle.
A summary spreadsheet with notes is available here:
https://spreadsheets0.google.com/ccc?key=ty1c-H56f0GxnL1Hk9LCmRg
I'm very interested in feedback, especially on the time estimates and
extra topics we should suggest to the TSC. See the notes at the top
and feel free to add items or estimates straight into the sheet -
anyone can view and anyone at Linaro should be able to edit.
-- Michael
Hi there. I ran a build of gcc-linaro-4.5+bzr99491 on ursa1 through 4
to see if there was any difference in build machines. The following
tests had different results:
* gcc.c-torture/compile/limits-structnest.c
* gcc.dg/graphite/block-4.c
* largefile.c
* obj-c++.dg/template-5.mm
* obj-c++.dg/template-5.mm
* obj-c++.dg/template-6.mm
* obj-c++.dg/template-6.mm
* objc/execute/class-4.m
I suspect that they're all caused by running the testsuite in parallel
and the host running out of memory. limits-structnest takes around
850 MB of RAM and passes on the machine with swap (ursa1) and fails on
the others. block-4.c takes 2:35 to run and timed out on ursa1 and
passed on the others which may be due to ursa1 swapping heavily while
running a limit test in parallel. The obj-c tests show various forms
of killed, and suggest that they were killed due to another process
taking all the memory.
I'll change the machines to use the full 1 G of memory, run the test
suite in sequential mode, and see how things go. I haven't
investigated largefile.c - it's a PCH test and these fail randomly.
Regarding block-4.c, it takes 155 s to run which is too close to the
default 300 s for my taste. Should we add a dg-timeout-factor 4.0 to
it similar to block-3.c?
-- Michael
Missed sending this out earlier this week.
== GCC ==
Progress:
* Sync'd with Andrew about T2 performance stuff.
* Spent some time investigating what could be done for divmodsi4
improvements . Working through the various phases. Not done tree level
stuff for a while so my knowledge of the API is a a bit rusty.
* Some upstream bugzilla duty.
Plans:
* Continue looking at divmodsi4 improvements.
* Continue looking at excessive VFP moves.
* Look at binutils + neon issue.
* Performance kick-off meeting
Meetings:
* 1-1s
* Linaro toolchain meeting
* Andrew Stubbs meeting for 1 hour about T2 performance.
Absences:
* April 13th - Internal ARM conference. Not at desk all day.
* April 15 – 26 -> Booked.
* May 9-14 - LDS Budapest
Hi,
libunwind:
* started to look on how to resume from a given stack frame:
* other platforms use setcontext
* setcontext is not implemented on ARM (glibc)
* the *context functions have been marked obsolescent in Posix
* http://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html
pandaboard:
* gdb doesn't find separate debug info of libraries that have been put into
a multiarch directory (#758619)
Note: I'll be out of office to attend a class till (including) Friday.
Regards
Ken
A rough agenda for today's call. I'll put this on the wiki after the call.
1. Go over what we are all doing today - roughly
Areas of investigation that we are looking at for near term.
a. divmodsi4 work.
b. Unnecessary VFP to integer register moves because of addressing
modes availability.
c. Thumb2 constants work
d. Additional areas for headroom in DENBENCH.
e. Coremark regressions fix up
f. Revisions causing major regressions in coremark
2. Find a way of replicating the benchmarking results and make sure we
get similar results to Michael and we are doing roughly the same
thing.
3. Regular bi-weekly call following the Toolchain WG meeting ? Or do
we organize another call ?
