== String routines ==
* Wrote a thumb optimised strchr
- As expected it's got nice performance for longer runs but at
sizes <16 bytes it's slower, and a lot of the strchr
calls are very short, so it's probably not of benefit in most cases
( https://wiki.linaro.org/WorkingGroups/ToolChain/Benchmarks/InitialStrchr?ac…
)
* Wrote a neon-memcpy
- As previously found with memset, it performs well on A8 but
poorly on A9 - it does however do the case where
the source/destination isn't aligned quite well even on A9 ; the vld1
unaligned case works with relatively little penalty.
(it performs comparably to the Bionic implementation - mine is a
bit faster on shorter calls, Bionic is better
on longer uses - I think that's because they've got some careful use
of preloads where I have so far got none).
I'm on holiday up to and including 5th April.
Dave
== GCC ==
Progress:
* Investigated excessive VFP moves . Investigating ways forward.
* Went through some of the test results with 4.6 RC2 upstream - looking
through test results etc.
* Setup SPEC2k6 cross on my Linaro machine.
* Waiting for my new Panda board sometime next week.
* Some small bug fixes upstream. Need to rework a couple of
documentation patches after review.
Plans:
* Continue looking at excessive VFP moves.
* Continue to look at some patches upstream.
* Finish working through Thumb2 speed tickets.
* Set up new Panda board.
* Start looking at DENBench results and identify
potential speed up areas.
Meetings:
* 1-1s
* Linaro toolchain meeting
Absences:
* March 30th (maybe): WC Cricket Semi-final. (Ind v Pak)
* April 15 – 26 -> Booked Holiday.
* May 9-14 - LDS Budapest
RAG:
Red:
Amber:
Green:
Current Milestones:
| Planned | Estimate | Actual |
qemu-linaro 2011-04 | 2011-04-21 | 2011-04-21 | |
Historical Milestones:
finish qemu-cont-integration | 2011-01-25 | 2011-01-25 | handed off |
first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 |
qemu-linaro 2011-03 | 2011-03-08 | 2011-03-08 | 2011-03-08 |
== maintain-beagle-models ==
* benchmarking/testing of the TCG locking fix: oddly benchmarks
seem to come out with less slowdown (1% or less) than a system
mode bootup/shutdown. (I used scimark and dhrystone. scimark
is the same speed, which is to be expected because we spend all
our time doing floating point emulation. I was expecting a bigger
perf hit on dhrystone, though.)
* submitted patches to make qemu fail cleanly if you ask for more RAM
than a board supports
== merge-correctness-fixes ==
* tested the Neon element load/store instructions; wrote patches to
fix UNDEF handling (which are blocked waiting for the patch pipeline
to be drained) and confirmed there aren't any other bugs.
There is a meego patch to use helper functions for multi-element
load/store which is apparently to avoid overflowing a TCG buffer:
need to test and upstream this.
* investigated android qemu tree for any missing correctness fixes:
looking through the changelog I think we have fixes upstream for
everything that was fixed in the android tree.
== other ==
* patch: fix versatilepb/realview handling of multiple nic options
* patch: better diagnosis of more nics requested than board supports
[this is needed to get the vexpress patch committed]
* reviewed a patch to add ARMv4/v4T support to qemu
(mostly consists of making sure we UNDEF in the right places)
* meetings: toolchain, standup, pdsw-tools, 1-2-1
Current qemu patch status is tracked here:
https://wiki.linaro.org/PeterMaydell/QemuPatchStatus
Absences:
Holiday: 22 Apr - 2 May
9-13 May: UDS, Budapest
(maybe) ~17-19 August: QEMU/KVM strand at LinuxCon NA, Vancouver
Hello,
Implemented a patch to apply SMS in the presence of instructions with
REG_INC_NOTE. (this occurs in telecom/autocor thus SMS needs to be run
with -fno-auto-inc-dec
flag to be applied)
Sent a merge request to gcc-linaro for the SMS patches.
Thanks to Andrew Stubbs for his help.
https://code.launchpad.net/~eres/gcc-linaro/SMS_doloop_for_ARM
I intend to send a request to gcc-linaro.4.6 as well.
Thanks,
Revital
Hi,
* resubmitted and committed store sink patch to trunk, I'll commit it
to gcc-linaro-4.6 next week
* submitted autodetection of vector size patch to gcc-patches, I'l
commit it next week
* started testing a patch that makes mvectorize-with-neon-quad the default
* DenBench: found some more cases where vectorization of strided
accesses using vzip/vuzp causes degradation. Since Richard is making a
lot of progress with vlsd/vst, I think it doesn't make sense to spend
too much time on vzip/vuzp, and I am going to run DenBench without
this patch.
Ira
Philipp Kern <trash(a)philkern.de> writes:
> On 2011-03-23, Goswin von Brederlow <goswin-v-b(a)web.de> wrote:
>> Also does the testing transition consider the Built-Using? If I specify
>> 'Built-Using: gcc-4.5 (= 4.5.2-5)' will the package be blocked from
>> entering testing until gcc-4.5 (= 4.5.2-5) has entered and block gcc-4.5
>> (= 4.5.2-5) from being replaced from testing?
>
> It doesn't need to. All we want is compliance on the archive side so that the
> sources are not expired away, as long as that binary is carried in a suite.
> No need to involve britney at that point.
>
> Kind regards
> Philipp Kern
Not quite. For ia32-libs it would be nice if ia32-libs could be blocked
from testing as long as the source packages it includes aren't in
testing. Currently that is solved by building against testing in the
first palce. But that is something we can live with.
As a side note the debian-cd package needs to also consider Built-Using
when creating source images. Will the Sources.gz file list multiple
entries for a source if multiple versions are relevant?
MfG
Goswin
Hi,
2009/11/2 Mark Hymers <mhy(a)debian.org>:
> On Mon, 02, Nov, 2009 at 12:43:42PM +0000, Philipp Kern spoke thus..
>> Of course it is a sane approach but very special care needs to be taken when
>> releasing to ensure GPL compliance. So what we should get is support in the
>> toolchain to declare against what source package the upload was built to
>> keep that around.
> We haven't implemented that yet for the archive software but it's on the
> TODO list (and not that difficult). None of us have had time to do the
> d-d-a post from the ftpteam meeting yet, but I'll make sure information
> is in there about it.
>
> I'm hoping to the archive-side support done in the next week or so.
Squeeze has already been released, cross toolchains were not released
along Debian main, but found at Emdebian repository.
Marcin Juszkiewicz has been working out cross compiler packages for
armel as part of his work for Linaro, which I attempt to include into
Debian main archive. As a result of the work done, linux-armel,
binutils-armel, eglibc-armel are merged into a single source package
named `cross-toolchain-base', the package is not optimal, but once we
got multiarch support, it should be renamed to `binutils-armel' (or
similar name) and use linux and eglibc libraries and headers provided
by multiarch.
Along this package I also plan to upload `gcc-4.5-cross' (#590465).
At the moment we are targeting one target architecture on two build
hosts ('{amd64,i386}->armel'), not sure if it is desired to be
supported on more build hosts. Target architecture support might grow
up in future, but right now it is not a priority.
Not sure if that is an issue for someone? Comments?
Best regards,
--
Héctor Orón
"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."
-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
== Last week ==
* Committed STT_GNU_IFUNC changes to binutils.
* Submitted the STT_GNU_IFUNC changes to GLIBC ports. Got feedback
on Friday, which I'll deal with this week.
* Worked on the expand and rtl-level parts of the load/store lane
representation, with new optabs for each operation. This seems
to be working pretty well, but I still need to make some changes
to the way the existing intrinsics work.
* Wrote a patch to clean up the way we handle optabs during expand,
so that the new optabs mentioned above will need a bit less
cut-&-paste. Submitted upstream. Got some positive feedback.
* Committed testcase for PR rtl-optimization/47166 upstream.
== This week ==
* Deal with GLIBC feedback.
* More load/store lanes.
Richard
* Linaro GCC
Tested and merged both the latest Linaro merge requests, and various bug
fixes to the Shrink Wrap optimization from CS, into Linaro GCC 4.5.
Merged and tested from FSF GCC 4.6.
Richard and Ramana have approved some of my upstream patches! I just
need to wait for stage one so I can commit them upstream. I'll commit
them internally when I get time to do the final integration test.
Continued benchmarking GCC 4.6 with the patches merged from GCC 4.5.
Decided to discard a couple of extra patches since they don't appear to
be of any value.
* Other
On leave Wednesday to Friday playing daddy. :)
* Future Absence
Away Monday 28th to Friday 1st April.
----
Upstream patched requiring review:
* Thumb2 constants:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html
* ARM EABI half-precision functions
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html
* ARM Thumb2 Spill Likely tweak
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html
* NEON scheduling patch
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
Hey
I'm trying to extend the *link: specs to pass a different
-dynamic-linker depending on the float ABI. But I didn't manage to
build a construct which would preserve the order of the flags; if I do
something like:
%{msoft-float:-dynamic-linker V1} %{mfloat-abi=softfp:-dynamic-linker V2}
Then I get V2 for "-mfloat-abi=softfp -msoft-float" instead of V1.
In gcc/gcc.c I found some docs on spec file syntax; I see one can use
%{S*&T*} and %{S*:X}, but apparently %{S*&T*:X} isn't allowed, so I
can't manipulate the value. I tried to use
%{msoft-float*:-dynamic-linker V1} %{mfloat-abi=softfp*:-dynamic-linker V2}
but that gives the same effect (the msoft-float flags are
grouped together in the original order and put first, then the
mfloat-abi=softfp are grouped together in the original order and put
second).
I didn't manage to get %{msoft-float*:%<msoft-float -dynamic-linker V1}
to work; in fact I didn't get supressions to work.
Any idea?
Thanks!
PS: float-abit=softfp/soft-float are just convenient examples; the
actual target is to use different -dynamic-linker for hard vs soft
float-abi
--
Loïc Minier
