(sent early this week since I'll be in the conference all Friday)
RAG:
Red:
Amber:
Green:
Current Milestones:
| Planned | Estimate | Actual |
Historical Milestones: [trimmed the 2010 ones]
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 ==
* wrote most of a patch to properly implement prlimit64 syscall
in usermode -- needs checking/testing
* wrote most of a patch to allow boards to specify their min/max/default
RAM size rather than having a single qemu-wide default; this would
let us specify RAM size on the beagle model (currently hardwired)
* retested the patch I wrote late last year which fixes TCG's locking
problems by having interrupting signals/threads just set a flag which
we check in every TB (rather than trying to mess with the TCG graph
in a totally unsafe and crashprone way). Slowdown: about 3.5% on
"boot Linaro nano on vexpress to rootprompt and shutdown again".
I shall see if I can persuade people that this is a price worth
paying for not randomly crashing in thread-heavy code :-)
== merge-correctness-fixes ==
* Wrote/submitted patchset which fixes VRECPS edge case handling
(mostly NaN related)
* Wrote/submitted patchset which fixes Neon VLD of single
element to all lanes
* Wrote/submitted patch which fixes qemu to work on an ARM host
where the host C code has been built in Thumb mode
== other ==
* attended QEMU Users Forum in Grenoble
* meetings: toolchain, standup, pdsw-tools, arch q&a
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
9-13 May: UDS, Budapest
(maybe) ~17-19 August: QEMU/KVM strand at LinuxCon NA, Vancouver
Short week
* libffi patch accepted upstream
* eglibc integration of string routine changes
- I have something that works but it's more complex than I'd like
(to get it to fall
back to the C code on stuff I haven't optimised for).
* Trying a neon memchr; tried a really simple 8 byte a loop version - it's
quite slow on both A8 and A9; branching on the result of comparisons
done in the neon is not simple.
* Porting jam bug 735877 chromium using d32 float; it was passing
vpfpv3 rather than using the default when configured without neon.
On holiday tomorrow (Friday).
Dave
Hello,
Experiment with aes benchmark from DENbench.
Continue my experiments with SMS which includes re-implementing an old
patch to insert reg-moves in free slots rather than greedily before the
definition as is done in the current implementation.
Thanks,
Revital
Hi,
* submitted store sinking patch to mainline
* started testing auto-detection of vector size patch
* DENBench - some benchmarks are still unstable, I am looking into
stable regressions, adjusting and fixing the cost model for them
Next week:
Sunday and Monday - holidays
Ira
Dave did an investigation earlier in the year into Cortex-A9 and
RealView PBX support in QEMU. The write-up is available here:
https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs/QEMURealViewPBX
Dave and Peter: could you please review it?
I've now closed out the blueprint. I'd like to do similar reports on
other outputs and will attack vexpress next.
-- Michael
Hi Michael, Andrew,
Mounir just pointed out that our non-Ubuntu LP projects (like gcc-linaro,
gdb-linaro etc.) are now also included in the LP work-item tracking
statistics (http://status.linaro.org/linaro-toolchain-wg.html). This
didn't happen in the past due to a Launchpad issue that has now been fixed.
This seems to be working out nicely, except for one issue: what about the
gcc-linaro-tracking project? I have a couple of bugs that are fixed in
Linaro GCC, and are also fixed in mainline GCC, but they still show up as
an "in-progress" work-item in the status tracker (there are a whole bunch
more of those assigned to Andrew as well). The reason for this is the LP
records have an associated gcc-linaro-toolchain project entry, and this is
set to "Fix Committed", but not "Fix Released" ... probably because GCC
4.6.0 is not yet released?
Now, on the one hand it does make sense to include the -tracking project in
the work-item statistics, because they *do* reflect important tasks:
namely, to make sure that the changes indeed land in the upstream
repository. However, having them all show up as "in progress" until the
community makes a new GCC release does not seem very helpful: this is not
in our control, and our work is in fact done once the patch is committed
upstream.
Therefore my suggestion: we should immediately mark -tracking bugs as "Fix
Released" (not "Fix Committed"), as soon as the corresponding patch is
committed upstream (and thus our work on the problem is completed).
Thoughts? Does this make sense? Will this mess up any of the other
purposes for which we currently use the -tracking project?
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
Hi Dave. I had a little play with cortex-strings and did some
benchmarks on my Tegra 2. Images are attached.
I've added two scripts to cortex-strings:
scripts/bench-all.sh runs all the routines on all variants and records them
scripts/plot.py plots the results from above
ploy.py corrects for the benchmark overhead by doing a linear fit to
the null 'bounce' results and subtracting this fit.
You should be able to a autogen; configure; make; bash
scripts/bench-all.sh | tee log.txt; python scripts/plot.py log.txt.
I'm sure you have your own favourite tools though.
The string routines look good. Lumpy in funny ways though...
-- Michael
[Sorry, forgot to CC: the list]
Hi Ira,
Thanks for the feedback.
On 6 March 2011 09:20, Ira Rosen <IRAR(a)il.ibm.com> wrote:
> > So how about the following functions? (Forgive the pascally syntax.)
> >
> > __builtin_load_lanes (REF : array N*M of X)
> > returns array N of vector M of X
> > maps to vldN
> > in practice, the result would be used in assignments of the form:
> > vectorX = ARRAY_REF <result, X>
> >
> > __builtin_store_lanes (VECTORS : array N of vector M of X)
> > returns array N*M of X
> > maps to vstN
> > in practice, the argument would be populated by assignments ofthe
> form:
> > vectorX = ARRAY_REF <result, X>
> >
> > __builtin_load_lane (REF : array N of X,
> > VECTORS : array N of vector M of X,
> > LANE : integer)
> > returns array N of vector M of X
> > maps to vldN_lane
> >
> > __builtin_store_lane (VECTORS : array N of vector M of X,
> > LANE : integer)
> > returns array N of X
> > maps to vstN_lane
> >
>
> How do you distinguish between "multiple structures" and "single structure
> to all lanes"?
Sorry, I'm not sure I understand the question. Could you give a couple
of examples?
The idea is that the arrays above really are array types, regardless of the
actual type of the thing we're accessing (which might be a larger array
than the bounds above say, or which might be an array of structures
or a structure of arrays). That should be OK because arrays alias
their elements.
Richard
Hi Matthias,
in last week's meeting you raised the question what, if any, code from the
Linaro GDB repository could be useful for inclusion into the natty GDB
package. I've now reviewed the contents of the repository, and my
suggestion would be to use everything in Linaro GDB 7.2, except for this
commit (which changes the branding to "Linaro GDB"):
revno: 32969
committer: Ulrich Weigand <uweigand(a)de.ibm.com>
branch nick: 7.2
timestamp: Wed 2010-09-22 19:18:38 +0200
message:
2010-09-22 Ulrich Weigand <uweigand(a)de.ibm.com>
* src-release: Support gdb-linaro packages.
gdb/
* version.in: Set to Linaro GDB version number.
* configure.ac (PKGVERSION, BUGURL): Refer to Linaro.
* configure: Regenerate.
gdb/gdbserver/
* configure.ac (PKGVERSION, BUGURL): Refer to Linaro.
* configure: Regenerate.
gdb/doc/
* configure.ac (PKGVERSION, BUGURL): Refer to Linaro.
* configure: Regenerate.
(Instead, the branding ought to be set as appropriate for the Ubuntu
package. Maybe with an additional reference to Linaro, just as with GCC?)
I've created a snapshot of the Linaro GDB 7.2 branch using the command
bzr diff --prefix a/:b/ -r32965..
and then manually removed changes to
src-release
gdb/version.in
gdb/configure.ac
gdb/configure
gdb/gdbserver/configure.ac
gdb/gdbserver/configure
gdb/doc/configure.ac
gdb/doc/configure
I've left in the new file ChangeLog.linaro for documentation purposes, but
if you prefer this could of course be removed as well.
The resulting patch is appended here. (Note that I'd recommend to continue
updating the patch from Linaro GDB as further changes make it in.)
(See attached file: linaro-gdb.patch)
I've then added the patch to the natty GDB package. Since it touches a
completely distinct set of files compared to the existing list of patches
in the package, it can be added to the series file at any arbitrary point.
I've built the resulting compiler on i386, arm, and ppc64, and it strictly
improved the test results on all three platforms:
i386 without patch:
# of expected passes 16161
# of unexpected failures 114
# of expected failures 72
# of untested testcases 9
# of unresolved testcases 1
# of unsupported tests 69
i386 with patch:
# of expected passes 16331
# of unexpected failures 24
# of expected failures 72
# of untested testcases 9
# of unresolved testcases 1
# of unsupported tests 69
Fixed test case failures are from:
gdb.base/break-interp.exp
gdb.base/foll-fork.exp
gdb.base/printcmds.exp
(These are just test suite cleanups, no actual code changes.)
ppc without patch:
# of expected passes 15350
# of unexpected failures 74
# of expected failures 53
# of untested testcases 15
# of unresolved testcases 1
# of unsupported tests 63
ppc with patch:
# of expected passes 15350
# of unexpected failures 55
# of expected failures 53
# of untested testcases 15
# of unresolved testcases 1
# of unsupported tests 63
Fixed test case failures are from:
gdb.base/printcmds.exp
gdb.threads/local-watch-wrong-thread.exp
gdb.threads/watchthreads.exp
(These are just test suite cleanups, no actual code changes.)
arm without patch:
# of expected passes 15343
# of unexpected failures 270
# of unexpected successes 1
# of expected failures 65
# of untested testcases 11
# of unresolved testcases 2
# of unsupported tests 70
arm with patch:
# of expected passes 15686
# of unexpected failures 46
# of unexpected successes 3
# of expected failures 63
# of untested testcases 11
# of unresolved testcases 1
# of unsupported tests 69
Fixed test case failures are from:
gdb.base/break-interp.exp
gdb.base/corefile.exp
gdb.base/foll-fork.exp
gdb.base/gcore.exp
gdb.base/gdb1555.exp
gdb.base/pr11022.exp
gdb.base/printcmds.exp
gdb.base/recurse.exp
gdb.base/relativedebug.exp
gdb.base/step-test.exp
gdb.base/watch-cond.exp
gdb.base/watch-read.exp
gdb.base/watch_thread_num.exp
gdb.base/watch-vfork.exp
gdb.gdb/selftest.exp
gdb.mi/gdb792.exp
gdb.mi/mi2-syn-frame.exp
gdb.mi/mi2-var-display.exp
gdb.mi/mi2-watch.exp
gdb.mi/mi-syn-frame.exp
gdb.mi/mi-var-display.exp
gdb.mi/mi-watch.exp
gdb.pie/corefile.exp
gdb.server/ext-attach.exp
gdb.threads/attachstop-mt.exp
gdb.threads/attach-stopped.exp
gdb.threads/linux-dp.exp
gdb.threads/local-watch-wrong-thread.exp
gdb.threads/pthread_cond_wait.exp
(This represents much of the bug fix work that went into Linaro GDB.)
Let me know if there's any further information you need, or anything else I
can do to help get the Linaro changes into natty GDB.
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