== QEMU ==
* Finished off a first cut of the 64bit helper patch to QEMU
- Gave it to Peter and have reworked most of the things he commented on
* This also lead into a bit of a rabbit hole of finding various
generic QEMU threading issues
* Tested Peter's 11.08 QEMU release
(I used linaro-fetch-image-ui for the first time to grab the
release images; quite nice, hit
a couple of issues but much nicer than crawling around the site
to find where the hwpacks
are).
== Other ==
* Pinged gcc patches list for more comments on 64bit atomic patch
I'm on holiday the week of 22nd (i.e. the week after next).
Dave
== GDB ==
* Re-tested Linaro GDB 7.3 on Versatile Express (native
& remote testing).
* Committed patch to re-enable remote thread test cases
(#804401) to mainline and Linaro GDB 7.3.
* Reviewed Yao's latest Thumb-2 displaced stepping patch.
== GCC ==
* Patch review week.
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
RAG:
Red:
Amber: OMAP3 patch upstreaming is slower progress than hoped
Green:
Current Milestones:
|| || Planned || Estimate || Actual ||
||qemu-linaro 2011-08 || 2011-08-18 || 2011-08-18 || ||
Historical Milestones:
||qemu-linaro 2011-04 || 2011-04-21 || 2011-04-21 || 2011-04-21 ||
||qemu-linaro 2011-05 || 2011-05-19 || 2011-05-19 || n/a ||
||close out 1105 blueprints || 2011-05-28 || 2011-05-28 || 2011-05-19 ||
||complete 1111 planning || 2011-05-28 || 2011-05-28 || 2011-05-27 ||
||qemu-linaro-2011-06 || 2011-06-16 || 2011-06-16 || 2011-06-16 ||
||qemu-linaro-2011-07 || 2011-07-21 || 2011-07-21 || 2011-07-21 ||
== linaro-qemu-11.11 ==
* put together release candidate tarball for 2011.08 release, tested
* added a workaround for omap kernel bug LP:727781 which had been fixed
in 2.6.x but has resurfaced in 3.0
* tarball now ready and only needs releasing next week
== 64-bit-sync-primitives ==
* reviewed David Gilbert's qemu patches to support 64 bit sync primitives
== upstream-omap3-patches ==
* testing/reading Avi's memory API patches to see how they fit in or
clash with the qdevification and other omap3 patches
== other ==
* more investigation/thought about LP:823902 -- qemu bug running
multithreaded programs in linux-user mode
* Manned Linaro demo stand at ARM Partner Meeting (Tue, Wed)
* Meetings: GSoC student x2, toolchain, toolchain standup, 1-2-1
Current qemu patch status is tracked here:
https://wiki.linaro.org/PeterMaydell/QemuPatchStatus
Absences:
15-19 August: KVM Forum and LinuxCon NA, Vancouver
== GCC ==
=== Progress ===
* Linaro sprint last week - one day of fun with broken laptop.
* Looked at how we could get BUILTIN_VECTORIZE_CONVERT work to allow
vectorizing some of the floating point conversions.
* Fixed PR50022 . Couple of iterations.
* Internal training for 2 days.
* Dusted off a couple of my old patches and sent them out after testing.
* Next to get back to old VFP and ivopts patch.
* Looked at a testfailure with -mvectorize-with-neon-quads with Ira .
=== Plans ===
* Continue to look at the test failure with mvectorize-with-neon-quad
* Finish off optimize_size patch based on comments.
* finish off case for handling tbh instrucitons.
* Commit fix for PR50022
* Look at some of the issues with VFP moves and try and get forward with it.
* Look at BRANCH_COST results.
Meetings:
* 1-1s
* TCWG calls
* GNU Toolchain planning meeting.
* Some patch review and bugzilla triaging.
Absences.
* 1st Aug - 5th August - Linaro sprint.
* 8th - 9th August - Internal training.
* 29th Aug - Sept. 2 - Holiday booked and approved.
* 31st Oct - 4th Nov - Linaro Summit Orlando - Travel to be booked.
== This week ==
* Looked a bug report that the fix for LP #736007 had caused regressions
on powerpc-darwin. It turned out to be a target-specific bug; the
backend has the same const_vector code as i386 and spu, but the fix for
PR34856 was never applied there. I'll submit the patch (and backport to
Linaro 4.6) once the bug submitter has had a chance to test it.
* Experimented with -falign-loops. Found that it triggered a bug in the
ARM minipool layout code. Posted patch upstream and committed.
Backported to 4.6.
* Committed patch to allow globs in define_bypass.
* Updated auto inc/dec patch after comments from Bernd and Stephen.
I'm pretty happy with it now, but there are a couple of prerequisite
patches I need to sort out first.
* Started getting those prerequisites ready.
* Decided that we needed something a bit more subtle than my original
insn_rtx_cost patch: at the moment, we simply don't use rtx costs
for lvalues. Wrote a series of patches to "improve" the rtx_cost
interface, including providing the outer operand number and an
indication of whether the rtx is an lvalue or an rvalue.
* Upgraded my laptop. This turnted out to be more eventful than
anticipated, and ended up taking a whole day.
== Next week ==
* Post auto inc/dec preparatory patches for review. Hopefully post
an RFA for the pass itself.
Richard
Hi,
* worked on getting the remote unwind support for ARM upstream
* noticed when building a recent android image of the
linaro_android_2.3.4 branch for the panda the init.rc attempts to mount
wrong partitions
* tracked down the commit and opened a bug
* linaro android team fixed it real quick
* started to integrate libunwind into Andriod
* two issues here:
- the build system requires an Android.mk (while libunwind is
autoconf+libtool based)
- libunwind uses some interfaces/headers that are not provided by the
bionlic libc
Regards
Ken
On Thu, Aug 04, 2011 at 12:03:00PM -0700, Taras Glek wrote:
> Recently we have been looking at how to squeeze more performance out
> of our toolchain for building Firefox on Android. Mike Hommey
> integrated GCC 4.6 into the android NDK and has been testing
> performance (with mixed results
> http://gcc.gnu.org/ml/gcc/2011-08/msg00096.html).
You should definitely be trying to build using the Linaro 4.5 and 4.6
compiler branches; they are pretty much guaranteed to give you better
performance, and if they don't, we're on the hook to fix it quickly! All
the patches go upstream, so there is no risk of you being stuck on a
fork -- it just makes everything you need available right now.
I'm copying the linaro-toolchain list to make sure that you get the
right people's attention (though if they weren't all coming back from
Connect in Cambridge this week they would have picked the email up
already).
> I like how Linaro is doing regular arm benchmarking, ie
> https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking/2011-…
We do much more than that, but it's not as easy to find right now; for
instance http://ex.seabright.co.nz/helpers/benchcompare is Michael's
regular release benchmark.
> . Would you be interested in adding a Firefox-based benchmark? As a
> large application it is a good testbed for LTO, FDO and other
> aggressive optimizations.
Totally. Let's do it. Can you give me an idea of what boards you are
testing the build on today? Do you have a test suite that we could run
in a reasonable timeframe (hours, not days)?
> We are also looking at setting a developer-friendly android ROM with
> oprofile, perf, systemtap, gdb, debug symbols, etc. It might even be
> beneficial for us to use newer kernels as we exlore options like
> kernel-assisted ld.so relocations, etc. That seems to similar to
> what Linaro provides in the evaluation ROMS. Is there any chance of
> Linaro providing developer-friendly "evaluation" ROMs for retail
> phones like the Nexus S?
It's indeed pretty similar (we just call them LEBs), and Zach will be
really interested in working with you on this.
As for supporting actual released phones, it lies somewhat outside of
our optimal operating model, and we don't have any hardware available. I
guess we could do a spin for a specific model if we had enough of them
to use by a set of engineers in the different teams. They are so
expensive, though. Do you guys have lots of them?
--
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs
Hi there. This is a heads-up that the name of the Toolchain group
releases will change slightly with next weeks release. We're dropping
the respin suffix (the -0) to line up with the new whole of Linaro
naming convention.
What was:
gcc-linaro-4.6-2011.xx-0.tar.bz2
gdb-linaro-7.2-2011.xx-0.tar.bz2
qemu-linaro-0.15-2011.xx-0.tar.bz2
will now be:
gcc-linaro-4.6-2011.xx.tar.bz2
gdb-linaro-7.2-2011.xx.tar.bz2
qemu-linaro-0.15-2011.xx.tar.bz2
Earth shattering, eh? I've taken the opportunity to write up our
naming convention at the same time:
https://wiki.linaro.org/WorkingGroups/ToolChain/Naming
-- Michael
Dave Martin <dave.martin(a)linaro.org> writes:
> However, there's not really anything fundamentally
> architecture-specific about this problem, and ideally the solution and
> the directives should not be architecture-specific either.
> One option which appeals to me is to have some directives which can
> exist across all architectures, and do something analogous to what
> .set push and ,set pop do on MIPS.
FWIW, this sounds like a really good idea to me. I won't argue about
the syntax (I have no particular preference).
> I feel that the environment should also include global,
> target-independent state such as the current macro mode (.altmacro
> versus .noaltmacro) and current ELF section stack state, but not
> symbols or macro definitions themselves.
Sounds reasonable. To state the obvious, we'd have to make the existing
target-dependent groupings (like .set push/pop on MIPS) work with this
new scheme, but those directives musn't affect this extra target-independent
information. So the new directives would interact with both the
traditional .pushsection and the traditional target-dependent directives,
even though those two features would otherwise remain independent.
That is, .pushsection and .set push/pop operate on conceptually
separate stacks whoses pushes and pops can be freely mixed.
But .pushsection and the new directives would need to be
strictly stacked; pops must have the same form as their
corresponding pushes. Combinations of .set push/pop and
the new directives would also need to be strictly stacked.
Nothing a bit of code can't handle though.
Richard
Hi all,
On ARM, we've now hit the problem a few times of temporarily
overriding the assembler state (or rather, not being able to do this
reliably). For example, sometimes there's a need to assemble a few
instructions for a different architecture version so we can optionally
execute or skip them at run-time is not really possible at present.
This sort of feature is especially useful in macros but can be useful
elsewhere too.
There seem to be some target-specific solutions to this problem
already. MIPS has its "option stack", maintained by .set push and
.set pop directives. From the documentation, it sounds like this
saves/restores a somewhat comprehensive set of state, but doesn't make
much syntactic sense on arches which use .set to define symbols (i.e.,
most arches). PowerPC also has .machine push and .machine pop, but
those only act on one specific aspect of the assembler state, and
therefore aren't as portable a concept.
However, there's not really anything fundamentally
architecture-specific about this problem, and ideally the solution and
the directives should not be architecture-specific either.
One option which appeals to me is to have some directives which can
exist across all architectures, and do something analogous to what
.set push and ,set pop do on MIPS.
My names would be .pushenv and .popenv, but obviously, they can be
named any way people like. (For now I'm stealing groff's
"environment" terminology to refer to such saved and restored state --
hence "env". Again, the nomenclature is arbitrary.)
These directives would save and restore a target-specific set of
state, which the philosophy that anything that can reasonably be
changed with a directive mid-file can also be saved and restored with
.pushenv/.popenv. Effectively, .popenv would be equivalent to issuing
the necessary set of assembler directives to restore the assembler
state to whatever it was at the last .pushenv (including the state of
the environment stack itself)
I feel that the environment should also include global,
target-independent state such as the current macro mode (.altmacro
versus .noaltmacro) and current ELF section stack state, but not
symbols or macro definitions themselves. Currently, neither the macro
mode nor the behaviour of .previous is reliably restorable after being
changed (unless I missed something). This can result in unexpected
behaviour after a macro which switches sections or changes the macro
mode. This seems unfortunate since on most arches there is no
syntactic difference between a machine instruction and a macro
invocation -- hence in the presence of macros, the only time you're
really 100% certain what .previous will do is immediately after a
.pushsection or .section directive (which obviously is not much use).
Comments are welcome -- at the moment this is just a fuzzy idea for a
feature which might prove useful.
I haven't investigated the implementation implications -- maybe it
could be built straightforwardly around the current MIPS directives.
Cheers
---Dave
