== Progress ==
* Bank Holiday on Monday
* Got symbol_ref split benchmarking going
* Hot/Cold partitioning in PGO:
* https://blueprints.launchpad.net/gcc-linaro/+spec/hot-cold-partitioning-in-…
* Investigated and fixed all compile-time failures in SPEC
* Investigated and fixed a silent code-gen fault in SPEC
== Next Week ==
* Look at symbol_ref split benchmarking results
* Hot/Cold Partitioning:
* Investigate remaining silent code-gen faults and non-termination
issue in SPEC
* If failures are fixed start profiledbootstraps and tests on the
central boards.
== Future ==
* Look at Cards for Vectorization, PGO and LTO with Michael.
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
== Progress ==
* Validation of my vext patch in big-endian mode proved that proper
support would be non-trivial.
Spent a lot of time writing a self-testing executable test, which
works in both big and little endian modes.
Posted an updated patch which makes no optimization in big-endian.
After discussion with Ramana, I will post a 2nd patch which improves
the testing in big-endian mode.
* In the process, wrote a patch to fix 3 other testcases which used to
fail in big-endian mode.
* Received no answer from the original contributor of bswap16 support patch.
== Next ==
* Have my vext patch accepted on trunk.
* Continue with bswap16 support.
(Short week: 3 days)
Current Milestones:
|| || Planned || Estimate || Actual ||
|| clean up kvm-qemu cp i/f || 2012-09-20 || 2012-09-20 || ||
|| fake-trustzone || 2012-10-15 || 2012-10-15 || ||
Also planned: general keeping up with kernel changes; upstream patch
review; qemu-linaro releases. May change dates to align with overall
KVM plan for the quarter when that is finalised.
Previous Milestones:
||cp15-rework || 2012-01-06 || 2012-06-23 || 2012-06-24 ||
||a15-lpae-support || 2012-07-13 || 2012-07-20 || 2012-07-20 ||
== clean-up-kvm-patches ==
* patches as they stand look good; currently blocked waiting
for changes to go into kernel side
== track-kvm-abi-changes ==
* thinking about some interesting corner cases in accessing
cp15 state via KVM, notably how userspace should get at the
cache ID registers, which are exposed by hardware as a "select"
and "read value of selected register" cp15 register pair.
Consensus seems to be that the kernel should deal with converting
this into a simple interface that userspace can use to just
read all the ID register state at once.
== other ==
* fixed breakage in ARM TCG host support (recent changes had failed
to account for the ABI requirement that 64 bit arguments to functions
must be passed in even-odd register pairs)
* KVM bootwrapper: pushed 64-bit-addresses-in-dtb patch to main repo;
reviewed patch from Guodong Xu adding uInitrd support
KVM blueprint progress tracker:
http://apus.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&…
-- PMM
The Linaro Toolchain Working Group is pleased to announce the 2012.08
release of the Linaro Toolchain Binaries, a pre-built version of
Linaro GCC and Linaro GDB that runs on generic Linux or Windows and
targets the glibc Linaro Evaluation Build.
Uses include:
* Cross compiling ARM applications from your laptop
* Remote debugging
* Build the Linux kernel for your board
What's included:
* Linaro GCC 4.7 2012.08
* Linaro GDB 7.4 2012.06
* A statically linked gdbserver
* A system root
* Manuals under share/doc/
The system root contains the basic header files and libraries to link
your programs against.
Interesting changes include:
* Enable threaded gold linker in Linux package
The Linux version is supported on Ubuntu 10.04.3 and 12.04, Debian
6.0.2, Fedora 16, openSUSE 12.1, Red Hat Enterprise Linux Workstation
5.7 and later, and should run on any Linux Standard Base 3.0
compatible distribution. Please see the README about running on
x86_64 hosts.
The Windows version is supported on Windows XP Pro SP3, Windows Vista
Business SP2, and Windows 7 Pro SP1.
The binaries and build scripts are available from:
https://launchpad.net/linaro-toolchain-binaries/trunk/2012.08
Need help? Ask a question on https://ask.linaro.org/
Already on Launchpad? Submit a bug at
https://bugs.launchpad.net/linaro-toolchain-binaries
On IRC? See us on #linaro on Freenode.
Other ways that you can contact us or get involved are listed at
https://wiki.linaro.org/GettingInvolved.
Summary:
* Identify the root cause of performance regression for the "split2" patch.
* Validate Linaro binary toolchain prerelease.
Details:
1. Identify the root cause of performance regression for the "split2" patch.
* Code alignment is the root cause for the performance regression
(Michael reproduced it with "__attribute__ ((aligned(16)))").
* "build-id" section is the root cause of result difference from
cbuild test (the additional section makes the function address
different).
* Workout a small case to show the impact of code alignment on performance.
2. Linaro binary toolchain 2012.08 prerelease validation. All tests pass.
Absence:
* Annual leave: Aug. 24.
Plans:
* Linaro binary toolchain 2012.08 release.
* Start shink-wrap work.
Best regards!
-Zhenqiang
== Progress ==
* Fixed problems with my patch for "constant vec permute operation for
the vext instruction" blue-print, validated in cbuild.
* Ported it to trunk and submitted for review. R.Earnshaw requested
validation on big-endian. I need to upgrade my qemu to have it
supported.
* Compiled my Neon intrinsics testsuite with LLVM (version 3.2 trunk 160543).
It compiles at O0/O1/O2/O3, but only O0 produces the expected results.
Errors include: vset_lane, vld3, and vld4.
* Started looking a bswap16 support
== Next ==
* Have my "constant vec permute operation for the vext instruction"
patch accepted on trunk
* Continue with bswap16 support.
== Progress ==
* Follow up from 2012.08 Toolchain release
* Updated Wiki pages
* Start working on symbol_ref split benchmarking.
* Backport to PR54212 done upstream to 4.6 and 4.7
* Started picking up Hot/Cold partitioning in PGO blueprint:
* https://blueprints.launchpad.net/gcc-linaro/+spec/hot-cold-partitioning-in-…
* Got SPEC running locally and I think I have reproduced Ramana's failures.
== Next Week ==
* Bank Holiday on Monday
* Investiagte SPEC failures in Hot/Cold PGO
* Get symbol_ref benchmarking going properly
== Future ==
* Look at Cards for Vectorization, PGO and LTO with Michael.
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
(cc'd to linaro-toolchain to archive)
Hi Matt. I've had a look at the manual builds you tried to spawn.
Here's what I did to run cbuild locally to test it:
* cd linaro
* bzr branch lp:cbuild
* cd cbuild/slaves
* cp -a example `hostname`
* cd `hostname`
* make -f ../../lib/build.mk final/gcc-4.8+svn190558.stamp
I'm not proud of the whole 'slaves/$hostname' setup, but it is what it is.
Results are in $version, such as gcc-4.8+svn190558. The build tree is
in $version/gcc/default/build. Nuke using rm -rf final results
$version. See lib/common.mk and override the email address etc in
local.mk to stop build results going out You should put a proxy in
$http_proxy or ~/.wgetrc to reduce the download cost. Please add to
the cbuild README.
A nit: we use the Debian versioning scheme so the version should be
4.8~svn190558, i.e. a SVN checkout leading up to 4.8. Compare with
4.7+svn1234, which is a SVN checkout of the 4.7 branch.
The tarballs look generally good. I've spawned them into the a9hf
queue as that's what we benchmark on. Note that they're low priority
due to not having 'linaro' in the name.
-- Michael
Zhenqiang's been working on the later split 2 patch which causes more
constants to be built using a movw/movt instead of a constant pool
load. There was an unexpected ~10 % regression in one benchmark which
seems to be due to function alignment. I think we've tracked down the
reason but not the action.
Compared to the baseline, the split2 branch took 113 % of the time to
run, i.e. 13 % longer. Adding an explicit 16 byte alignment to the
function changed this to 97 % of the time, i.e. 3 % faster. The
reason Zhenqiang and I got different results was the build-id. He
used the binary build scripts to make the cross compiler, which turn
on the build ID, which added an extra 20 bytes ahead of .text, which
happened to align the function to 16 bytes. cbuild doesn't use the
build-id (although it should) which happened to align the function to
an 8 byte boundary.
The disassembly is identical so I assume the regression is cache or
fast loop related. I'm not sure what to do, so let's talk about this
at the next performance call.
-- Michael
