We now do a SPEC ref run when benchmarking. I've updated the
linaro-toolchain-benchmarks scripts to handle the changes and spawned
some historical builds to do comparisons. All earlier builds have
been archived to prevent confusion.
The human readable summary is now also included in the results. See:
http://ex.seabright.co.nz/benchmarks/gcc-linaro-4.6-2012.02/logs/armv7l-nat…
for an example.
Half an hour to build, 26 hours to run. Not too bad.
-- 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
I'd like to announce a change in how the Linaro Toolchain group notify
about our monthly releases. In the past we've sent one email per
product to the linaro-announce list. From this week forward a summary
of all products will be included in the main, end of month
announcement instead.
We'll continue to send a per product emails to the linaro-toolchain
list when the mid-month release is available. If you'd like to get
things two weeks early, please subscribe[1]. You can filter on the
word '[ANNOUNCE]' to filter out the development chatter. A RSS feed
is also available[2].
-- Michael
[1] http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[2] http://feeds.launchpad.net/linaro-toolchain/announcements.atom
All,
I need to supply a Linaro toolchain "aligned" (same source code)
bare-metal compiler to a group doing benchmarking on A15.
First off my assumption is that we will write our own boot and semi
hosting code. (semi-hosting for TI emulators/simulators is different
than ARM RDI semi-hosting.)
I was planning on looking at the two toolchains here[1] and here [2]:
[1] https://launchpad.net/linaro-toolchain-binaries
[2] https://launchpad.net/gcc-arm-embedded
I was then going to build a hybrid that was newlib based but appropriate
for armv7-a (instead of cortext-m3) and maybe even -mtune'ed for A15.
However looking at the gcc-arm-embedded release more[3] I see that it
supports ARMv7-R. It supports both thumb and non-thumb modes, both
softfp and hardfp ABIs.
What would I really gain by building my own? For app code the user
should be able to add -mtune=cortex-a15 and still be compatible with the
pre-built R4/R5 libraries. The only performance difference should be in
the library code and that should be only pipeline tuning if I understand
the difference between armv7-a and armv7-r correctly.
Am I missing something? Should I build my hybrid anyway?
[1] https://launchpadlibrarian.net/88152755/readme.txt
[BTW: has the below project been obsoleted by the gcc-arm-embedded one?
Perhaps gcc-arm-embedded should be referenced in the description of
the page below.
https://launchpad.net/linaro-toolchain-unsupported ]
Thanks,
Bill
Committed the 4.6.3 merge to Linaro GCC 4.6.
Merged from FSF 4.5 to Linaro GCC 4.5.
Thought about how to do register-class allocation for NEON v. core
registers case. Discussed the problem at the GCC performance meeting.
Lots of interesting discussion was had. I have some interesting
experiments to do, but the first step needs to be to get my 64-bit
operator patch to work correctly.
Tried to track down the problems in my NEON-immediates patch. The
problem is that it's putting constants in different pools in stage 3 to
what it does in stage 2. Presumably this is something to do with the
pool-offset attributes in the instruction patterns? My patch has caused
it to switch from using 'fldd' to using 'vmov' in some cases (the
instructions are aliases, but it's indicative of a different machine
description pattern in the compiler), but I don't know why the change
would be different between the different bootstrap stages? I made some
alterations to switch it back to `fldd` when it wasn't supposed to
change, but bootstrap still fails. More investigation required...again.
Rewrote the NEON one's-complement patch and posted it upstream.
Tracked down the cause of the bootstrap failures in my NEON 64-bit
shifts patch: out-of-range shift amounts were not handled leading to
ICEs. Reworked the constant shift handling cases, and resumbitted the
patch for testing. It's failed again. A job for next week.
Summary:
* Multilib test for linaro toolchain.
* Code size test for embedded toolchain.
Details:
1. Multilib test for linaro toolchain.
* Workaround the marm/march=armv5t build by setting the
MULTILIB_DEFAULT to mthumb.
* Investigate how to make multiarch and multilib work together.
Based on current multiarch/multilib patches, it is hard to make them
work together. Trying to set the default multilib dir to the multiarch
dir to workaround it. Need more work to build libgcc.
2. Code size investigation for embedded toolchain.
* Try to test benchmarks.
* Run gcc regression test with –mthumb/-mcpu=cortex=m3/-Os and
analyze the new failed cases. After skipping the cases based on
scan-assembler, warning/error message, etc, there are 5 new failed
cases in three categories:
(1) gcc.target/arm/neon/vst1_lanes64.c: known issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51631
(2) Wrong optimization for gcc.dg/atomic-lockfree.c,
gcc.dg/atomic-noinline.c and gcc.dg/pr30951.c.
(3) g++.dg/eh/filter1.C abort in libsupc++.
Plans:
* Root cause the new failed cases.
* Continue to investigate the multilib/multiarch issue.
Best regards!
-Zhenqiang
Hi Michael,
Spec2000 is now running successfully: there are results at
http://ex.seabright.co.nz/benchmarks/gcc-linaro-4.7%2bbzr114965/logs/armv7l…
However, they seem to have been run in 'train' mode, and none of the
runs are long enough for comparison.
I thought the a9-ref queue was supposed to run in full 'ref' mode?
Andrew
Hi,
OpenEmbedded:
* removed the recipe for building the linux-linaro-3.1 kernel
* add support for the default OE-core kernel
* allows to build the linux-yocto_3.2 kernel for the
qemuarmv7a MACHINE using a vexpress defconfig
* updated the wiki on how to build OE-core with meta-linaro
https://wiki.linaro.org/KenWerner/Sandbox/OpenEmbedded-Core
* worked OEMetaLinaroCard
* started to talk to CI folks about automating the oe-core+meta-linaro
* wrote a script that automates the process
* ran it on tcserver01 to build the qt4e and sato images against the
source gcc-linaro-4.6-2012.02
Regards,
Ken
Hi Ken. In follow up to our 1-on-1 yesterday, here's what I'd like done next.
The goal is to use OE Core as a release test suite. The releases are
tarballs so we can keep the current recipe format and punt bzr support
for later. The first step is to be able to reliably build a release
in the cloud or validation lab.
In all cases keep the other teams in mind. Much of this is related to
Validation. Platform will be involved later. Ping them early.
Kernel:
We're starting with GCC and need a kernel to supply headers and to
boot some type of ARMv7 image. I don't want a linux-linaro recipe as
people will use it and it's too early for that.
Find a kernel, preferably from OE Core, that is recent, ARMv7, >= 512
MB RAM, and works well with qemu-linaro. Prefer vexpress-a9, else
OMAP?
Talking:
Say Hi to Validation re: EC2 and plans
Say Hi to the ARM landing team re: vexpress upstream support
Say Hi to Beth Flanagan re: Yocto's existing auto builders and any hints
Cloud builds:
Find out who is already doing OE builds in the cloud and how
Run a build locally and time
Push ~/downloads into the cloud, build, and time[1]
Figure how much this build will cost in dollars
[1] c1.xlarge might be best. Builds are normally I/O bound and the
cloud is I/O poor. Put /tmp and other chunks in a tmpfs? EC2 rounds
up to the nearest hour as well.
If the cloud is too expensive then we'll get a machine installed.
S3 for storage:
(only proceed if affordable)
Use S3 for storing the input tarballs
Use S3 either as a pre-mirror by serving over HTTP, or use s3cmd to
sync down the tarballs before starting the build
Scripting:
Re-use existing scripts if feasible. Integrate with LAVA providing we
can run exactly the same scripts on a laptop for debugging.
Script the bitbake, OE meta layer, and Linaro meta layer setup.
Script the configuration including setting the release tarball URL and
GCC preferred version.
Script the build and result capture, especially the log, any ICEs, and
the final sizes
Future:
OE can grab a repository seed then update based on that. Check if the
bzr backend supports this. If so, play with seeding to do tip builds.
Let me know what you think then we'll spawn blueprints. Let's keep an
eye on this as it's sounding expensive.
-- Michael
