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
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
== Issues ==
It would be nice to have perf installed on the porter boxes in the
canonical data center as well if we are allowed to run benchmarks
there. Filed RT request.
==Progress===
* Understood STB_GNU_UNIQUE_NOTE - Helped fix a problem with compiz
crashing but then it was a very nice testcase to investigate the
toolchain issue with. Thanks Alexandros.
* Merged pending patches.
* ABI fix
* Fix for ICE - LP bug 942307
* Off sick on Monday.
* Did some work to improve code generation for addressing modes in VFP
registers.
* Did some work in setting up SPEC2k for running hc partitioning
patches. Still needs to be completed.
=== Plans ===
* Ping configure.ac changes.
* Complete pending benchmark run with hc partitioning and look at
results with hc partitioning and run things. Was unable to run the vfp
benchmarks today as ex.seabright.co.nz was down.
* Resurrect partial-partial PRE
Absences.
* 1 week holiday sometime before that - to be booked.
* Linaro Connect Q2.12 - May 28 - June 1 - travel booked - hotel to be booked.
Hi Ken. This month's release is next week. Let's be aggressive and
see if we can use your meta-linaro layer to check the source release.
I want to use tcserver01 in the validation lab instead of the cloud
until we know how much it costs. I've added you an account and done a
test build to check that the dependencies are there. There's a shared
directory in /home/shared that includes downloads and a sstate-cache.
The machine seems fast enough for the job.
The tarball should be ready around Tuesday next week. Once ready,
could you mix it in with the meta-linaro layer, do a build, boot the
rootfs in qemu, and document as you go? Anything past that is
welcome.
It's all manual but a nice proof of concept. Can we check the binary
build as well?
-- Michael
