== QEMU ==
* Wrote the context routines for Eglibc, including those that QEMU uses
These pass all the context tests I could find, including QEMUs coroutine
tests, and with them QEMU seems to boot OK. I've got a full eglibc test
run going at the moment, but I don't think anything else
== General ==
* Tidying things up and updating my list of statuses
== String routines ==
* Adding strchr and strlen to eglibc; tests running at the moment.
Dave
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro
== QEMU ==
* Wrote a fix for bug 883133 (code buffer/libc conflict); spent some
time testing it because
I wasn't sure whether the crash I was seeing after that was my fix not
being complete or actually
bug 893208.
* Got it to boot with -cpu 486; without that it's triple faulting in
a divide jus
On 7 December 2011 20:36, Andrew Stubbs wrote:
> Hi all,
>
> I've copied all those who made commits to GCC 4.6 this month.
>
> Could you please give me a sentence or two for the release notes?
Support for 64bit __sync* primitives on ARM.
Dave
___
lina
== String routines ==
* Sent updated memchr to the eglibc list
== 64 bit atomics ==
* Ran a set of timing consistency tests that a colleague had sent me
while I was off; Panda passed those, so time
doesn't appear to be going backwards or anything, so that's not the
problem with membase.
* Pu
== 64 bit atomics ==
* Still fighting membase
* Cleaned up a bunch of other issues, but I'm back at an 'expiry'
issue, where the test
stores some data with a fixed expiry time and then waits until after
it should have expired,
and checks it has. Except on ARM it sometimes doesn't expire qui
== 64 bit atomics ==
* Nailed one more of the membase tests; again this was a test
harness race condition (which I've reported here:
http://code.google.com/p/moxi/issues/detail?id=2&thanks=2&ts=1321037460 )
In this case there were two calls to write) performed on the
server, yet the t
=== 64 bit atomics
* I got the race in membase down to a futex issue, and asking dmart
pointed me at a kernel bug that
affects recent kernels where a fix had gone in about a month ago.
That was a nasty one!
* I've still got a few bugs left; most are turning out to be timing
races in the test co
== 64 bit atomics ==
* I've been building and testing membase
* Version 1.7.1.1 source builds OK (after turning off -Werror due to
some of their curious type naming)
* The git version fails to build - it doesn't seem consistent
* 1.7.1.1 passes simple tests, but there are 3 tests in its tes
== 64 bit atomics ==
* Thanks to Ramana for OKing my gcc patches; and Richard for
committing them - I've backported these to the gcc-linaro branch
and pushed it - hopefully those will pass OK!
== String routines ==
* Sent my memchr patch to upstream newlib, received comments,
tweeked, and
I've just tried rerunning some benchmarks on my panda, which I
reinstalled recently and am getting
some odd behaviour:
The kernel is 3.0.0-1404-linaro-lt-omap
For example:
simple_strlen: ,102400, loops of ,62, bytes=6.054688 MB, transferred
in ,20324707.00 ns, giving, 297.897898 MB/s
simple_s
== String Routines ==
* Built and tested a newlib with my memchr in - ready to go with a
bit of tidy up.
* Followed up on my eglibc patch submission by a comment suggesting
the use of --with-cpu pointing back at the previous discussion.
== 64 Bit atomics ==
* Updated gcc patch based on Raman
== String routines ==
* Got eglibc testing setup happy at last
- Note that -O3 builds generally seem to give a few more errors
that are probably worth looking at
- -march=armv6 -mthumb hit some non-thumb1 instructions (normally
non-lo registers), again worth looking at
- Cross testing
On 27 September 2011 14:16, Christian Robottom Reis wrote:
> On Tue, Sep 27, 2011 at 09:47:33AM +0100, Ramana Radhakrishnan wrote:
>> On 26 September 2011 21:51, Michael Hope wrote:
>> > Saw this on the linaro-multimedia list:
>> > http://lists.linaro.org/pipermail/linaro-multimedia/2011-Septemb
== String routines ==
* Having got agreement on ignoring the triplet for picking the
routine, I'm just testing a patch,
but fighting a qemu setup.
* Found the binfmt binding for armeb was wrong (runs the le
version); filed bug with fix in
Dave
_
On 19 September 2011 00:48, Michael K. Edwards wrote:
> Please coordinate with Jon Masters at RedHat/Fedora and Adam Conrad at
> Ubuntu/Debian on this. (Cc'ing the cross-distro list, through which the
> recent ARM summit at Linux Plumbers was organized.)
OK, let me summarise for the new people o
== String routines ==
* Tidying up bits of cortex strings for the release process
* Nailing down the behaviour of config.sub and the config systems in
gcc, binutils and eglibc
== Other ==
* A discussion on synchronisation primitives on various CPUs that
started on the gcc list
- looking
OK, so we seem to have agreement here that what we want is autodetect
for eglibc and
forget about the triplet; well technically that probably makes my life
easier, and I don't
think it's too hard a sell.
Dave
___
linaro-toolchain mailing list
linaro-too
As mentioned on the standup call this morning, I've been trying to get my head
around the way different parts of the toolchain using the config scripts and the
triplets. I'd appreciate some thoughts on what the right thing to do
is, especially
since there was some unease at some of the ideas.
My
== String routines ==
* Trying to understand my strlen behaviour that Michael identified
- Found lots of ways of making the faster case slower, but none of making
the slower case faster!
- Perf not being available on Panda (bug 702999/843628) made it
difficult to
dig down
On 5 September 2011 17:40, Christian Robottom Reis wrote:
> On Mon, Sep 05, 2011 at 03:21:49PM +1200, Michael Hope wrote:
>> memchr is good. memset could be better for blocks of less than 1k.
>> strchr gets second place but is eclipsed by newlib's version. strcmp
>> need work. strcmp is good.
>
On 5 September 2011 04:21, Michael Hope wrote:
> On Fri, Sep 2, 2011 at 4:08 PM, Michael Hope wrote:
>> Hi Dave. I've been hacking away and have checked in a couple of
>> benchmarking and plotting scripts to lp:cortex-strings. The current
>> results are at:
>> http://people.linaro.org/~michael
== QEmu ==
* Sent 64bit atomic helper fix upstream
* Basic boot time and simple benchmarks v Panda board
* Tested prebuilt images and Peter's latest post-merge QEmu tree
- The full Ubuntu desktop on an emulated Overo is a bit slow -
it's rather short on RAM
- The full Ubuntu desktop
== String routines ==
* Working through updating my eglibc patch for memchr, I think I'm
nearly there - took way too long
to persuade an eglibc make check to work cross (can't get native
build happy).
== QEMU ==
* Sent a new version of my QEMU patch for the atomic helpers to Peter.
* Tes
On 17 August 2011 12:09, Bernhard Rosenkranzer
wrote:
> Hi,
> is the Linaro toolchain (esp. gcc) useful on x86/x86_64, or is an
> attempt to use the Linaro toolchain with such a target just asking for
> trouble?
> (No, I'm not secretly an Intel spy ;) Just trying to have some fun
> with my desktop
== 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 li
== QEMU ==
* After discussion with Peter started writing QEMU fixup for 64bit
atomic helper version location.
* Sent fixes for soc-dma code to qemu list
* Trying to understand just how much of omap_dma's code is needed.
== Other ==
* Travelling to/from connect
* Wanted to dial into some
== 64 bit atomics ==
* Sent updated set of 64bit atomic patches to gcc list with fixes
from previous review
* Started hunting for other users of 64bit atomics than membase
jemalloc, sdl and boost lock free look like possibilities; but I've
not looked at them hard yet
== QEmu ==
* Released fi
== 64 bit atomics ==
* Updated gcc patches as per comments from Ramana and Joseph; build
currently cooking on Panda
== Qemu ==
* Testing Peter's pre-release, finding bug on beagle (that he
tracked down to x-loader change)
* Found cause of occasional SD card errors I was seeing (SD: CMD12
in
== String routines ==
* Sent a patch to libc-ports with modified configure scripts to add
subdirectories
for architecture specific ARM code, and the memchr.S from cortex-strings.
== 64 bit atomics ==
* Working through comments on my patches and the set of discussions about the
kernel inter
== 64 bit atomics ==
* Submitted patches to gcc patch list
- One comment back already asking if we should really change ARM
to have a VDSO to make checks of the user helper version easier
* Added thumb ldrexd/strexd to valgrind; patch added to bug in their
bugtracker (KDE bug 266035)
*
== Atomics ==
* Testing the libgcc fallback code with Nicholas's kernel patch -
and then fixing my initialisation code to use init_array's (thanks
Richard for the hint)
* Tidying stuff up after a review of my patch by Richard - the
sync.md is now smaller than the original before I started.
*
== 64 bit Atomics ==
* Wrote more test cases; now have a nice 3 thread test that passes -
and more importantly, it fails if I replace one of the atomic ops
by a non-atomic equivalent.
* Modified existing atomic helper code in libgcc to do 64bit
* Added init function to 64bit atomic helper to
On 16 June 2011 19:37, Marcin Juszkiewicz wrote:
> On czw, 2011-06-16 at 20:31 +0200, Marcin Juszkiewicz wrote:
>> There is a ftbfs on armel bug for postler:
>> https://bugs.launchpad.net/ubuntu/+source/postler/+bug/791319
>>
>> Attached test compiles fine on amd64 but fails on armel:
>>
>> 20:16
== String Routines ==
* Completed gathering the SPEC2k6 memcpy results, graphed them, sent them out
* Gathered SPEC2k6 memset results, graphed them, sent them out
== 64bit Atomics ==
* Modified gcc backend to do 64bit Atomic ops - the code looks good,
but I've not
done much testing yet.
==
== String routines ==
* Wrote a hybrid ARM/Neon memcpy - it uses Neon for non-aligned cases or
large (>=128k) cases
* polished up and sent out write up of workload analysis of denbench and spec
* Ran denbench with all memcpy and memset varients, graphed up results
- SPEC 2k6 is now c
== String routines ==
* Finally finished the ltrace analysis of the whole of SPEC 2k6 and
have written it up - I'll proof read it next week and then send it out
to the benchmark list.
* Ran memset and memcpy benchmarks of larger than cache sizes on A9
* memcpy on larger than cache sizes (or
* Profiling SPEC 2k6 still; about 3/4 of the latrace files are
generated but it's taking some hand holding with some of them
(e.g. finding one that makes millions of calls to a library function
that we're not interested in but generates a huge log, and hence
needs it excluding).
* Working thr
== String routines ==
* Gave up on perf on silverbell and redid it on ursa2; now have a
full set of perf figures and have updated the workload report to show
the spec
binaries that use significant time in libc and the routines they spend
it in; a handful of tests spend very significant amounts of
On 8 May 2011 13:55, Hakehuang wrote:
> Can there be something using pragma option to disable neon for each function?
I don't think there is a pragma like that for ARM at the moment;
Gcc does seem to have a
#pragma GCC target
and also function attributes for target options; but at the moment th
== Bug fighting ==
* Tracked bug 774175 (apt segfault on armel on oneiric) down to the
cortex-a8 branch erratum bug that we found as part of the bug jam a
few weeks
ago (affecting the more obscure vtk package) - Richard's existing
binutils fix should fix this.
== String routines ==
* Struggled
== String and Memory routines ==
* Profiled denbench with perf and produced a set of stats to show
which programs spent how much time in libc and how
much time was spent in each routine.While some of the
benchmarks are good (like aes) and spend almost no time in libc
some of the othe
== Bug triaging ==
* Bug 745843 (vtk ftbfs) got it down to a bad arm/thumb transition -
identified as a linker error and handed off to RichardS
* Bug 758082 (augeas ftbfs) tracked it down to overwrite of a
parameter in a variadic function before it got stacked; identified by
Ramana as another
i
- Back from holiday, short week.
== Porting jam ==
* We seem to have picked up a lot of ftbfs in the last couple of
weeks - which is unfortunate because it may well be too close to the
Natty
release to do anything about them
* Bug 745843 is a repeatable segfault in part of the build process
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/739374 is the
bug relating to the Tegra errata mentioned today.
Dave
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
== 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/ToolCh
Short week
* libffi patch accepted upstream
* eglibc integration of string routine changes
- I have something that works but it's more complex than I'd like
(to get it to fall
back to the C code on stuff I haven't optimised for).
* Trying a neon memchr; tried a really simple 8 byte a loo
== hard-float ==
* Updated libffi variadic patch and Sent updated libffi variadic
patch to the ffi mailing list.
== String routines ==
* Got a big endian build environment going
* Patched up memchr and strlen for big endian; turned out to be a
very small change in the end; and
tested it on q
* Investigated and fixed sqlite3 testsuite failure on ARM (bug 725052)
* Discussing libffi API changes with maintainer; hopefully he's
going to send out his comments today.
* Looking at how to upstream the string routine changes
* Need to look at big endian testing
* Testing QEmu pre-r
On 2 March 2011 18:44, John Rigby wrote:
> FWIW, Michael's recipe for building here
> https://code.launchpad.net/~michaelh1/+junk/cross-build has worked
> well for me.
It's OK for people familiar with toolchains; the problem is where you
have a subject specialist
who knows how to write C or ARM a
== ffi ==
* Sent variadic patch for libffi to libffi-discuss
* Worked through some suggestions from Chung-Lin, need to do some rework
== string routines ==
* memchr & strchr patch sent for inclusion in ubuntu packages
* tried sqlite's benchmarks - they don't spend too much time in the
C li
== String routines ==
* Copied an improvement I'd previously made to memchr (removing a
branch using a big IT block) to strlen
* Modified benchmark setup to build everything as a library to
fairly give everything a PLT overhead.
* Pushed optimised memchr and strlen and simple strchr into
cort
== String routines ==
* After some discussions about IT semantics managed to shave a
couple of instructions out of a couple of routines
* Got around to trying a suggestion that was made some months ago,
that LDM is faster than LDRD on A9's; and indeed
it does seem to be in some cases; those ca
On 2 February 2011 12:28, Peter Maydell wrote:
> On 2 February 2011 11:54, Peter Maydell wrote:
>> ie gcc wants (at least) 100M of RAM trying to compile a 190K sourcefile.
>> (and probably more overall since the board has 500MB RAM total and
>> it hit the out-of-memory condition).
>
> On a rerun
On 2 February 2011 10:47, Dave Martin wrote:
> On Tue, Feb 1, 2011 at 12:33 PM, David Gilbert
> wrote:
>> Hi,
>> What do people understand to be the expected semantics of IT blocks
>> in the cases below, of which there has been some confusion
>> in relation to
Hi,
What do people understand to be the expected semantics of IT blocks
in the cases below, of which there has been some confusion
in relation to a recent Qt issue.
The code in question had a sequence something like:
comparison
IT... EQ
blahEQ
TEQ
BEQ
The important bits here are t
SPEC
Tried to track down what was going on with lbm; it doesn't seem to
be repeatable on canis1; I'd previously seen it fail at O1 and work at
O0 and tried to chop down the flags between the two; but after adding
all the flags back in on top of -O0 it still worked and then I tried
-O1 again and i
On 26 January 2011 12:12, Dave Martin wrote:
> Hi Vijay,
>
> On Sat, Jan 22, 2011 at 9:59 AM, Vijay Kilari wrote:
>> Hello Dave,
>>
>> Thanks for this info.
>>
>> I have few more queries after looking at the results of memset on A9 & A8.
>> I agree that externel bus speed matters in comparision
=A9 Qemu=
I've spent most of the week looking at QEmu emulation of SMP A9. The
model (of a realview-pbx-a9) doesn't have any working block IO;
I spent some time looking at trying to get SD working and got part
way, but I fell back to using NFS root.
It seems to work OK for basic CPU emulation, a
Got a complete run of SPEC Train on Orion board - all working.
Kicked off a SPEC ref run - canis1 died.
Gathered a full set of 'perf record's for all of SPEC on silverbell;
and had a quick look through them;
there aren't too many surprises; a few things that might be worth a
look at though.
(Not a
Got h264ref working in SPEC; this was another signed-char issue (very
difficult one to find - it didn't crash, it just came out with subtly
the wrong result);
compiling that and sphinx3 with -fsigned-char and they seem happy.
With Richard's fix for gromacs that leaves just the zeusmp binary
that's
Continued looking at SPEC 2006.
The two ICEs I mentioned last week are gone on the Natty version of the
compiler, however the 4 programs that run and give the wrong
results still happen with the Natty version and the latest version from bzr.
The 4 failures are:
h264ref - still fails on bzr
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
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
Mostly more working with libffi; swapping some ideas back and forwards with
Marcus Shawcroft and it looks like we have
a good way forward.
Got an armhf chroot going, libffi built.
Got a testcase failing as expected.
Trying to look at other processors ABIs to understand why varargs works for
anyone
Hi,
Those of you use silverbell may be glad to know it's back up.
Be a little careful, if you shovel large amounts of stuff over it's network
the network tends to disappear.
(Not sure if this is hardware or driver)
Dave
___
linaro-toolchain mailing lis
Hi,
As mentioned on the standup, I just got an armhf chroot going, thanks to
markos for pointing me at using multistrap
I put the following in a armhfmultistrap.conf and did
multistrap -f armhfmultistrap.conf
Once that's done, chroot in and then do
dpkg --configure -a
it's pretty sparse i
* Benchmarking of simple package builds with various string routine
versions; not finding enough difference in the noise to make any large
conclusions
* Looking at the string routine behaviour with perf to see where the time
is going
- getting hit by the Linaro kernels on silverbell missin
On 29 November 2010 00:18, Michael Hope wrote:
>
> To add to the mix:
>
> Some ideas that are logged as blueprints:
> Using ARMv5 saturated instructions
> (https://blueprints.launchpad.net/gcc-linaro/+spec/armv5-saturated-ops)
> Using ARMv6 SIMD instructions
> (https://blueprints.launchpad.net/
Hand crafted a simple strchr and comparing it with Libc:
https://wiki.linaro.org/WorkingGroups/ToolChain/Benchmarks/InitialStrchr
It's interesting it's significantly faster than libc's on A9's, but on
A8's it's slower for large sizes. I've not really looked why yet; my
implementation is just the
Hi Richard,
As per the discussion at this mornings call; I've reread the TRM and I
agree with you about the LSLS being the same speed as the TST. (1 cycle)
However as we agreed, the uxtb does look like 2 cycles v the AND 1 cycle.
On the space v perf theme, one thing that would be interesting to
Short week.
Finally got external hard drive for my beagle - makes it sanely possible to
natively build things.
Got eglibc cross built (Thanks to Wookey for pointing me in the right
direction with the magic incantation of dpkg-buildpackage -aarmel
--target=binary) and
easily rebuilding . I have a
Hi,
I've been looking at some basic libc routine optimisation and have a
curious problem with memset and wondered if
anyone can offer some insights.
Some graphs and links to code are on
https://wiki.linaro.org/WorkingGroups/ToolChain/Benchmarks/InitialMemset
I've written a simple memset in bot
73 matches
Mail list logo
