Current Milestones:
|| || Planned || Estimate || Actual ||
||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 || || || ||
||track-kvm-abi-changes || || || ||
||fake-trustzone || || || ||
Overall KVM plan for 'do by end August': QEMU parts of this are a mix
of clean-up-kvm-patches and track-kvm-abi-changes blueprints, mostly.
http://cards.linaro.org/browse/CARD-167
== clean-up-kvm-patches ==
* did enough cleanup to be able to send a coherent initial RFC
patchset to qemu-devel/kvmarm.
== other ==
* upstream patch review, in preparation for QEMU 1.2 freeze next week
* put together qemu-linaro 2012.08 tarball (release next week)
KVM blueprint progress tracker:
http://apus.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&…
-- PMM
== GCC ==
* Back-ported patch to change vector alignment to 8
to FSF GCC 4.6 and 4.7 and Linaro GCC 4.6 and 4.7.
* Investigated mp3player benchmark regression with
Linaro GCC 4.7 backport of vector alignment patch.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
== Progress ==
* Started Linaro ramp up process
* Lots of admin, paperwork, and PC setup
* Successfully built compilers from Linaro and upstream trees
* Out of office Friday 10
== Next Week ==
* Out of office Friday 17
* Attend appropriate Virtual Connect sessions
* Do the 2012.08 release of the Toolchain
* Start working on symbol_ref split benchmarking.
== Future ==
* Find a small patch to GCC to use to pipeclean the submission process
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
Hello,
I've had a look at the mp3player performance regressions (just with *some*
data sets) with the vector-alignment patch. Interestingly it turns out
that the patch basically does not change the generated code for the hot
spot (inv_mdct routine) at all. (The *only* change is which bits of the
incoming pointer the run-time alignment check generated by the vectorizer
tests for. But this has no practical consequences, since the check itself
is not hot, and the *decision* made by the check is the same anyway --
everything is in fact properly aligned at runtime.)
The other difference, outside of code, introduced by the vector-alignment
patch is that some global arrays used to be forcibly aligned to 16 bytes by
the vectorizer, and they are now only aligned to 8 bytes. To check whether
this makes a difference, I've modified the compiler as a hack to always
force all global arrays to be 16 byte aligned. And interestingly enough,
this appears to fix this particular performance regression ...
Any thoughts as to why this might be the case? What are the
recommendations on the ARM hardware side as to what alignment is prefered?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
I have noticed gcc has a preference for generating UXTB instructions
when an AND with #255 would do the same thing. This is bad, because
on A9 UXTB has two cycles latency compared to one cycle for AND. On
A8 both instructions have one cycle latency.
--
Mans Rullgard / mru
== GCC ==
* Checked in patch to change vector alignment to 8
to GCC mainline.
* Started investigating benchmark regressions with
Linaro GCC 4.7 backport of vector alignment patch.
== GDB ==
* Checked in patch to fix hardware breakpoints on
non-4-byte aligned (Thumb) instructions.
* Checked in patch to properly report unsupported
watchpoint address/length combinations in gdbserver.
* Checked in patch to fix regression accessing /proc
files on older Linux kernels.
* Checked in 5 more patches to fix miscellaneous
test suite regressions.
* Re-tested GDB 7.5 pre-release on multiple platforms.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
[ Also posted to debian-arm; not cross-posted to avoid subscription
complaints... ]
Hi folks,
We're currently carrying patches in glibc in Debian (and Ubuntu) that
I wrote which are used to work out whether an ELF binary is hard-float
or soft-float. We're using these to allow us to do the right thing on
a multi-arch system, which is to pick a consistent set of binaries
(programs and libraries) at runtime; if you try to mix binaries using
different ABIs, you're prone to all kinds of weird and wonderful
results but generally badness occurs.
Upstream glibc have generally not been welcoming of these patches, and
I understand this; the approach taken (reading ARM-specific build
attributes) is far from clean and doesn't fit well in the design of
ld.so in particular. So, I've been looking into alternative methods
for achieving the goal of identifying ABI. After a couple of false
starts and discussion with some of the helpful toolchain and ABI folks
in ARM, I think we have a solution that will work well in the long
term. I just wish we'd thought about this *way* back when we first
started the armhf port, as it would have been much easier to work on
and standardise this back then. Modulo availability of time machines,
there's not much we can do on that front... :-)
What I'm proposing is to use two new values in the OSABI field in the
ELF header:
#define ELFOSABI_LINUX_ARM_AEABI_SF 65
#define ELFOSABI_LINUX_ARM_AEABI_HF 66
and use these values in the future for soft- and hard-float binaries
so that can unambiguously identify them.
There's already precedent for binaries using different values in this
field, with support in glibc for parsing and understanding
them. Adding more possible values is quite easy, assuming that the
maintainers are amenable. I'm about to post a similar message there.
I have a plan of attack for how to make a staged switch over,
deliberately to minimise any potential compatibility problems. See the
attached doc for that. It's deliberately not very specific in terms of
timeline, as that's something I'm hoping to get feedback
about. Comments very welcome; please point out if you think there are
problems with this approach, or if there are any more implementations
of toolchain / linker that will need to be addressed.
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
