RAG:
Red:
Amber:
Green:
Current Milestones:
|| || Planned || Estimate || Actual ||
||a15-usermode-support || 2011-11-10 || 2011-11-10 || 2011-10-27 ||
||upstream-omap3-cleanup || 2011-11-10 || 2011-11-10 || ||
Historical Milestones:
||qemu-linaro-2011-07 || 2011-07-21 || 2011-07-21 || 2011-07-21 ||
||qemu-linaro 2011-08 || 2011-08-18 || 2011-08-18 || 2011-08-18 ||
||qemu-linaro 2011-09 || 2011-09-15 || 2011-09-15 || 2011-09-15 ||
||add-omap3-networking || 2011-10-13 || 2011-10-13 || 2011-10-13 ||
||a15-systemmode-planning || 2011-10-13 || 2011-10-13 || 2011-09-22 ||
== a15-usermode-support ==
* A15 instruction support patches committed upstream in time for
upstream's 1.0 release
== upstream-omap3-cleanup ==
* some work on restructuring the omap3 patchset -- it's now basically
in the right order and the last 'touches several different
bits of code' jumbo patch has been split
== other ==
* sent some patches upstream which address the main things I
want to get into qemu 1.0 (PL041 audio support and fixing a
regression in handling multithreaded programs in linux-user mode)
* A15 KVM planning work and other preparation for Linaro Connect
* finally tracked down the qemu-on-ARM memory corruption: we
mmap the code generation buffer at 0x1000000 with MAP_FIXED;
unfortunately this is now in the middle of glibc's heap...
(filed as LP:883133)
* qemu now has a coroutine implementation which defaults to using
makecontext() if it is present. Unfortunately ARM eglibc provides
an implementation which always returns ENOSYS, which is a bit
tricky to detect with a compile time configure check (without
breaking cross-compilation support).
* these two things (and some other known bugs) mean that QEMU on
ARM hosts is basically broken, and will probably continue to be
since we don't have the spare resource to test and fix bugs
(beyond those which we need to fix for KVM-on-ARM)
* Looked at how to configure Firefox and how to build different parts of the
program. Usage of .mozconfig, myrules.mk and myconfig.mk.
* Tested the Talos framework. https://wiki.mozilla.org/Buildbot/Talos. I
think it would be good to use Talos for the browsing benchmarks. We can
discuss it further at connect.
* Preparing for connect.
Best Regards
Åsa
Summary:
* Exercise crosstool-ng and summarize the gaps.
Details:
* Exercise crosstool-ng
(1) Sync with lp:~linaro-toolchain-dev/crosstool-ng/linaro.
(2) Try to config linux-host-baremental-target an
mingw32-host-baremental-target.
(3) Try to build the toolchain for both embedded toolchain and
linaro-gcc-4.6-2011.10 with the config.
. C compiler for linux and mingw32 hosts and c++ compiler for
linux host can be built without any change.
. C++ compiler for mingw32 host can be built after PCH is disabled.
. GDB-cross build fail due to dependence packages.
* Gaps in crosstool-ng
(1) Improve GDB-cross scripts to download and build the dependence
packages: expat and ncurses. Or put expat and ncurses as
companion_libraries.
(2) To remove dependence, embedded toolchain requires more
prerequisites like zlib.
New config and scripts are required to support the packages.
(3) Currently, the embedded toolchain source packages are released
as a tarball, which includes gcc, gmp, etc. New scripts are required
to support it.
(4) To make sure the toolchain can run with lower version glibc like
redhat4/5, the embedded toolchain requires lower version native
gcc4.3.6 to build it.
To support it,
. Users can build the native gcc manually, or
. Enhance the scripts to add one step to build native gcc.
(5) All the default package configurations are different from
embedded toolchain internal build scripts.
Since the configurations in embedded toolchain had been tuned
and tested, we will change the configurations in crosstool-ng if they
do not match and not configurable.
The same rule will apply for linaro toolchain.
Plans:
* Write scripts to re-pack the embedded toolchain source packages.
* Add the supports for all prerequisites in crosstool-ng menuconfig.
Thanks!
-Zhenqiang
Posted a patch upstream to fix big-endian for generic tuning. This was a
simple omission from my previous patches.
Merged GCC 4.6.2 to Linaro GCC. It's still in testing now, so I'll have
to commit it sometime over the weekend or next week.
Looked at the benchmark results from Spec2000 running on both A8 and A9
systems, with and with NEON, and with various compiler options. Posted
the results in a spreadsheet (visible within Linaro only).
Begun making adjustments to generic tuning and started new spec2k runs
to see if they are beneficial. First, I'm trying A9 prefetch settings on
A8 to see how much damage it does. Next I'll try enabling the A8 NEON
tuning settings on A9 to see what happens there.
Prepared for travel next week.
Vacation Friday
Hi,
- Merged to gcc-linaro:
- widening shifts
- SLP features: support loads with different offsets and swap
operands if necessary
- Started rewriting SLP analysis to support operations with more than
two operands (towards SLP of conditions)
- Updated NEON presentation following Ramana's suggestions (thanks!)
- Suggested to Ramana to implement vcond with mixed types, created a
blueprint: https://blueprints.launchpad.net/gcc-linaro/+spec/vcond-with-mixed-types
- Vectorizer:
- updated vectorizer's webpage
- updated vectorizer's wiki page
- the usual maintenance
- Committed upstream two SLP data-ref analysis improvements: PR 50730
and PR 50819
Ira
Hi there. Connect is just around the corner. Have a look at:
https://wiki.linaro.org/MichaelHope/Sandbox/Q4.11Plans
for a summary of the toolchain sessions and hacking topics.
It would be great to have kernel and OCTO input in the ARM STM driver,
Kernel debugging, and KVM sessions.
-- Michael
Hi Folks,
Draft agenda for the performance meeting next week at Connect -
https://blueprints.launchpad.net/gcc-linaro/+spec/linaro-toolchain-performa…
Are there any topics that people would like to bring up during this
meeting other than the ones listed here ? I suspect that we'll
probably just have about 10-15 minutes for a topic in this case. I am
not considering discussing PGO related stuff in this session given
that we've got another session in which we can discuss this.
Thoughts ?
cheers
Ramana
Hi Folks,
I've been trying to capture what we want to do in terms of hacking
time and some of the performance related backlog that we have in the
system. I have done so here.
https://wiki.linaro.org/RamanaRadhakrishnan/Sandbox/Q411ConnectGCCPerfPlan
I'm on vacation tomorrow but should be picking email for sometime
during the day.
Thoughts about what else we could be doing in this area or if there's
a better way we could use our hacking time.
cheers
Ramana
---
At the moment ARM eglibc doesn't support the functions declared
in ucontext.h: getcontext(), setcontext(), swapcontext() and
makecontext(). Instead you get implementations which always
fail and set errno to ENOSYS.
QEMU uses these functions to implement coroutines. Although there
is a fallback implementation in terms of threads, there are reasons
why using the fallback is suboptimal:
* its performance is worse
* it will be less tested, because x86_64 and i386 both implement
the ucontext functions and so QEMU on those hosts will be using
different code paths
* I'm not aware of a good way at configure time to detect whether
getcontext() et al will always fail without actually running a
test binary, which won't work in a cross-compile setup. (If eglibc
just didn't provide the functions at all this would be much
simpler...)
We're going to care about performance and reliability of QEMU on
ARM hosts as we start to support KVM on Cortex-A15, so it would
be good if we could add ucontext function support to eglibc as
part of that effort.
Opinions? Have I missed some good reason why there isn't an
ARM implementation of these functions?
(I'm aware that the ucontext functions have been removed from
the latest version of the POSIX spec; however AFAIK there's no
equivalent functionality that replaces them so I think they're
still worth having implementations of for parity with other
architectures.)
-- PMM
