Does anyone have any experience of what can be profiled in the profiled
guided optimisations?
One of the problems with some of the string routines is that you can write
pretty neat fast routines that
work well for long strings - but most of the calls actually pass short
strings and the overhead of the
fast routine means that for most cases you are slower than you would have
been with a simple routine.
If Profile Guiding could spot that a particular callsite to say strlen() was
often associated with strings
of at least 'n' characters we could call a different implementation.
Dave
* Linaro GCC
lp:686381: C++ link failure on ARM
Reproduced the bug and posted my findings to the bug report - user error.
Changed the way the Linaro GCC version numbers are handled. Hopefully
the new system should be less distasteful to Matthias. Updated the GCC
release procedure document to match.
Organised and chaired a meeting to discuss GCC optimization
opportunities for ARM. It was well attended, and I think we had some
useful discussion. Spend quite some time preparing beforehand, and
writing it up afterwards. Next step is to come up with some actual plans
to implement something. I imagine we can discuss this at the sprint in
Dallas next month. See
https://wiki.linaro.org/AndrewStubbs/Sandbox/GCCoptimizations
* Upstream GCC
My upstream patch to fix ARM smlabb has been approved and committed to
GCC 4.6 (mainline). Only another three patches need approval now!
Continued testing upstream GCC 4.6 with both cross and native builds. It
appears to be in a buildable state now, with no extra patches required.
I've updated the Linaro GCC 4.6 branch with the buildable state.
* Other
Updated my ESTA, and added my security details to the airline bookings.
------
Future availability
20th Dec .. 3rd Jan - Vacation/Holiday
4th Jan .. 8th Jan - Business as usual
9th Jan .. 14th Jan - Linaro Sprint, Dallas
15th Jan .. 21st Jan - CodeSourcery/Mentor Annual Meeting, Scottsdale
24th Jan onwards - normal service restored!
Got SPEC2006 building on Silverbell (VExpress) and Canis1 (Orion). There
are still some issues;
The builds are still going (6 hours so far on a 1GHz A9 for a build and
'test' case), and the Silverbell one has hit an ICE on one of the tests that
looks like 635409,
and also looks like it needs some help getting Perl to work. The build on
Canis has only just started,
but hasn't got Fortran installed.
(The SPEC2006 tools build also failed in the Perl testsuite on sprintf.t and
sprintf2.t which seem to test integer
overflow cases in sprintf % fields)
Added a few of the kernel string/memory routines and bionic routines into my
string/memory graphs and
also ran the tests on the Orion board (similar to other A9 performance - no
surprise).
Wrote up a draft of an email to libffi-dev describing the varargs state; and
as I was doing it realised that
one of the ways didn't quite work and was more messy.
Using rdepends to find all packages using ffi, need to figure out if any
actually care about varargs.
Dave
== GCC ==
* Completed first successful bootstrap and regression test run
of GCC mainline on my IGEPv2 board.
* Worked on implementing fix for #617384
(.debug_line is wrong with -fpic)
* Worked on backporting fix for #662324
(Pointer type information lost in 4.5 debuginfo)
* Analyzed root cause of PR target/46883
(GCC ICE with error: unrecognizable insn)
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
Hi there. I've cancelled the weekly and standup calls for the next
two weeks. The next scheduled call is the standup call on Wednesday
the 5th of January. Please attend if you can as it's our last one
before the sprint.
See you then!
-- Michael
Hi there. The sprint is just around the corner and it's a good time
to think about how we can make best use of the week. I've put some
topics up at:
https://wiki.linaro.org/Events/2011-01-LinaroSprint/ToolChainWG
Please feel free to add to it. Have a think about anything that's
easier to do while everyone is in the same room - things like
discussions, kicking off some work, a bit of pair programming on a
problem, or anything that overlaps with another group or Ubuntu.
-- Michael
RAG:
Red:
Amber:
Green:
Milestones:
| Planned | Estimate | Actual |
finish virtio-system | 2010-08-27 | postponed | |
get valgrind into linaro PPA | 2010-09-15 | 2010-09-28 | 2010-09-28 |
complete a qemu-maemo update | 2010-09-24 | 2010-09-22 | 2010-09-22 |
finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 |
Progress:
* merge-correctness-fixes:
** Submitted patchset upstream to fix NaN propagation to
follow ARM ARM rules rather than x87 semantics:
http://patchwork.ozlabs.org/patch/75742/http://patchwork.ozlabs.org/patch/75743/
* maintain-beagle-models:
** Finished implementation of the OMAP NAND prefetch/postwrite
engine including its DMA support. Patches submitted to the
qemu-maemo upstream tree and merged by Juha:
http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/1
** Fixed the (cosmetic) bug
https://bugs.launchpad.net/qemu-maemo/+bug/622408
where we were complaining about "Unknown CMD52" when Linux probed
for the presence of SDIO cards. Fix merged into qemu-maemo:
http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/2
* qemu-continuous-integration:
** Discussion with Loic about setting up jobs on his Hudson
instance for testing qemu against snapshots/hwpacks.
* packageselection-arm-n-more-stable-vm-solution-for-arm
** Discussion about Ubuntu moving to using a qemu-maemo based
qemu for ARM purposes. The Ubuntu blueprint is
https://blueprints.launchpad.net/ubuntu/+spec/packageselection-arm-n-more-s…
We need to come to agreement about what parts of this are
going to be done by variously Linaro toolchain, Linaro
foundations and Ubuntu.
** I'm going through doing another rebase-and-package of
the Linaro qemu, and finishing off writing up the notes
on the process:
https://wiki.linaro.org/WorkingGroups/ToolChain/QemuReleaseProcess
Meetings: toolchain, pdsw-tools, pdsw-tools xmas lunch :-)
Issues:
* a number of qemu patches in progress are logjammed behind
the outstanding git pull request
* the dbgsym debug packages for linaro kernels seem to have
vanished:
https://bugs.launchpad.net/linaro-images/+bug/691192
Absences: (complete to end of 2010)
Fri 17 Dec - Tue 4 Jan inclusive.
2011: Dallas Linaro sprint 9-15 Jan. Holiday 22 Apr - 2 May.
Hi,
* I've spent some time for testing the patches that allow the GCC trunk
to bootstrap again on ARM and posted the results to gcc-testresults
* finally tested and posted the patch that optimizes the __sync_*
builtins (#681138) on gcc-patches
* investigated on the state of the crash utility on ARM (or rather its
prerequisites like kexec)
https://wiki.linaro.org/KenWerner/Sandbox/crash-utility
* I'm on holiday now :)
Regards
Ken
Hi,
On Wed, Dec 15, 2010 at 1:44 AM, Michael Hope <michael.hope(a)linaro.org> wrote:
> On Wed, Dec 15, 2010 at 1:05 PM, Steve Langasek
> <steve.langasek(a)linaro.org> wrote:
>> Hi Michael,
>>
>> On Wed, Dec 15, 2010 at 09:29:38AM +1300, Michael Hope wrote:
>>> Hi Steve. I'd like to hand the rest of this over to you if that's OK.
>>
>> Yep, we can take it from here. To be clear, is this an additional change
>> above and beyond what Matthias reports is currently in Ubuntu gcc
>> (http://lists.linaro.org/pipermail/linaro-toolchain/2010-November/000441.html),
>> and if so, in what version of Linaro GCC is it going to become effective?
>> Do we have documentation of what the relevant failure modes caused by this
>> change *look* like, so that we can at least be triaging them appropriately
>> until there's some documentation on how to fix the resulting bugs?
>
> There will be many failures in many packages. The problem is when you
> use conditional suffixes on instructions: previously the compiler
> would insert an implicit instruction before that; now we have to be
> explicit.
>
> The failures are easy to diagnose and fix. The build will fail with a
> message from the assembler along the lines of 'xxx instruction outside
> an IT block'. The fix is to find the inline assembly code, insert the
> appropriate IT instruction, and re-build. The assembler will validate
> the IT instruction against the following conditional instructions so
> the change is quite safe.
Did someone manage to find out which versions of binutils can silently
accept the IT instructions when assembling for ARM?
This affects what advice we should give on how to avoid breaking
upstream with our additions. The safest approach is #ifdefs, but it
will be better for maintenance if we can avoid this, since it will
render the code very messy.
Cheers
---Dave
Hi there. Some of the tr-* blueprints had work items in them and this
was interfering with the tools that the PM guys use. I've created new
engineering blueprints, pulled the work items across into them, and
added the new engineering blueprint as a dependency of the old TR.
Sorry for the blueprint spam. In most cases the new blueprint has the
same name and subject as the TR one, such as the TR:
https://blueprints.launchpad.net/linaro/+spec/tr-toolchain-4.5-in-distros
which is backed by the engineering blueprint:
https://blueprints.launchpad.net/gcc-linaro/+spec/4.5-in-distros
-- Michael
