The final version of the 'Building at -O3' writeup is at:
https://wiki.linaro.org/Internal/ToolChain/BuildingAtO3
This updates the SPEC 2000 results to show that there is a net win
which is held back by a bad (but understood) regression in one
benchmark.
Thank you all for your work on this,
-- Michael
Here's brief notes on running different benchmark variants across the
auto builders. Asa, could you pull these plus your notes into a wiki
page?
Spawn a job:
http://ex.seabright.co.nz/helpers/scheduler/spawn
Merge requests are automatically built. Otherwise, drop arbitrary
tarballs into cbuild@orion:~/snapshots and spawn <tarball name minus
extension>. For example, scp gcc-4.6.3.tar.gz
cbuild@orion:~/snapshots; spawn gcc-4.6.3 into a9-builder.
Jobs:
* gcc-version - build and test GCC
* benchmarks-gcc-version - run coremark, denbench, eembc against the
already built version
* benchmarks-spec2000-gcc-version - run spec2000
Queues:
* a9-builders: anything that can naive build a A9 compiler
* a9-ref: reference A9 boards
* a8-ref: reference A8 boards
Variables:
* BENCHMARKS = list, such as coremark spec2000 pybench - run these
benchmarks instead of the defaults
Variants:
* By default we build o3-neon
* See http://bazaar.launchpad.net/~linaro-toolchain-dev/cbuild/trunk/view/head:/l…
for all names
* Spawn a job with VARIANT_SRC = all and VARIANT_LIST = glob-pattern
Examples:
* VARIANT_LIST = o3-neon o3-vfpv3 (compare NEON with VFPv3D32)
* VARIANT_LIST = o3-neon-cortexa8 o3-neon-cortexa9 (compare
-mtune=cortexa8 vs -mtune=cortexa9(
* VARIANT_LIST = o3-neon-novect o3-neon (compare with/without the vectoriser)
-- Michael
Hi Ken, Thiago. Could you try your hand at writing cards for the
OpenEmbedded Core meta-layer and GDB and Android? Here are some past
cards:
https://linaro-public.papyrs.com/TCWG2011-GCC-O3https://linaro-public.papyrs.com/TCWG2011-OPENOCD-SUPPORThttps://linaro-public.papyrs.com/TCWG2011-WINDOWS-TOOLCHAIN
They cover:
* An introduction
* The why/advantages
* The what/features
* The how/steps
* Dependencies
* Acceptance criteria (which is a post-tense version of the body)
A card should cover three calendar months. Check the unknowns - we
need to investigate the acceptance criteria and make sure there is no
unexpected side work in there.
We use roadmap cards as the highest level of organising our work.
Cards are the interface between working groups and the TSC and sit at
the project brief / deep but concise level.
Draft them on the wiki (cf https://wiki.linaro.org/KenWerner/Sandbox)
and we'll go from there.
-- Michael
Hi,
184603 fixes an ICE we're running into with Android test builds.
Please pull it in ASAP so I don't have to mess with the CFLAGS as a workaround.
ttyl
bero
Hi Peter, Rusty. I've fleshed out the KVM blueprints a bit more at:
https://wiki.linaro.org/MichaelHope/Sandbox/Q1.12ToDo
Notable is adding validation and de-PENDING a few things.
I need to know the following things before talking to Validation and
Platforms about things that are in their queue:
* What's the host kernel? Christoffers, or a linux-linaro-kvm based
off his plus work in progress?
* What's the guest kernel?
* Anything special that needs to be in the host rootfs outside qemu
and libvirt?
Do you have a host and guest kernel .config that I can pass on to Platforms?
-- Michael
Hi,
GDB on Android:
* Set up cross compiling environment using both the Android toolchain
and
the Linaro toolchain.
* Tested Android and Mozilla GDB running as a native binary on the
Linaro Android image on qemu. None of them were able to see all
threads in a multi-threaded process. The same happens with a native
binary on Android talking to a gdbserver on localhost.
* I was able to produce an Android GDB 7.1.x binary which when running
on an i386 host talking to the Android SDK emulator sees all threads.
It is not able to generate a backtrace though.
* Carnival holidays.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
Investigated and produced and patch for bug lp936863.
Continued work on 64-bit shifts. I updated my neon shifts patch twice:
once to take -Os optimization into account, and once because I noticed
that the CC clobbers were being retained even after they were known to
be not required, and presumably this could be a bad thing.
Posted a patch to improve SI->DImode sign- and zero-extends that also
move values from core registers to neon registers.
Wrote a patch to implement negation in neon register, albeit at the cost
of a scratch register to hold the constant zero. This worked, but
insisted on loading the zero from memory, despite the fact that NEON has
a suitable instruction for loading zero.
Attempted to get "vmov dN, #0" to work. The problem appears to be that
DImode loads are handled by the VFP load pattern in vfp.md and that that
doesn't seem to DTRT for integer constants. I've got as far as trying to
figure out what it does do, but there's more to be done to get to the
bottom of the problem.
Tried to get the benchmarking going for 64-bit shifts. Unfortunately
ursa1 has been experiencing outages. Michael has been trying to fix it,
but so far I've not been able to run anything there. Instead, I've
launched benchmark runs via Michael's normal test infrastructure.
Hopefully this can replace the manual ones anyway. That would be more
convenient.
