* Linaro GCC
Continued work on 64-bit shifts. My patch for shifts in core registers
was rejected because I used conditional-execution before it's safe,
apparently, so I've spent some time looking at the alternatives.
First, conditional move instructions were unsatisfactory - the final
instruction sequence was longer and therefore less efficient.
Second, if_then_else instructions (basically conditional execution
expressed a different way) was to limited - there were no patterns
compatible with "or with shifted input" available in ARM mode, and no
patterns available at all in Thumb mode. I solved that easily enough, of
course, but the result was still unsatisfactory. In Thumb mode the
result was roughly equivalent (conditional-execution is constrained by
IT blocks), but in ARM mode it uses patterns that output two opposing
instructions at once, without allowing for the possibility of scheduling
or other optimization.
Third, I've tried putting in ordinary branches and relying on the
if-conversion pass to transform that to conditional execution. I had not
done this initially, partially because I didn't know how, but mostly
because the original implementation I was trying to replace resulted in
branches in the output code, and I was trying to improve on that.
Anyway, I've now figured out how to do that, and initial testing
suggests that the if-conversion really is working this time. Even if it
doesn't always, the other improvements to the shift sequence should
still give a boost.
My other patch, to do 64-bits shifts in NEON (and fall back to the above
code when register allocation sees fit) has not yet been reviewed.
* Linaro Connect
This week was Linaro Connect week. I could not attend the event in San
Francisco in person this time, so I took part in some of the morning
sessions remotely.
Linaro have switched to using Google Hangouts for the remote
participation, and it went really rather well. In the old system there
was an audio stream to listen to (on a 20 second delay or so, usually),
and an IRC room projected onto a large screen for remote attendees to
respond. The new Hangout system is effectively a simple in-browser
video-conference system that allowed us to not only see the room, but
also respond verbally in real time. The only disadvantage is the
10-person limit, but I never saw any room get near that all week.
I successfully attended several sessions and one regular meeting
remotely by these means. And no jet lag or eating so much!
Hi,
Made the GDB 7.4-2012.02 release:
* Learned about cbuild and how to use its services.
* Prepared a GDB Linaro 7.4-2012.02~rc1 tarball and ran on cbuild.
* Compared test results on ARM and i686 with the ones from 7.3-2011.12.
Investigated new failures, determining that all come from new
testcases added since the last release. One seemed important but
when investigated it turned out to be a bug in the hand-written
debug info for the testcase, which is wrong on ARM. I opened
bug reports on Launchpad for the new failures which are worth being
investigated for future releases. There are no regressions
in 7.4-2012.02 compared to 7.3-2011.12.
* Executed the release process for Linaro GDB.
* Started exploring GDB on Android.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
Hi,
OpenEmbedded-Core:
* tested the external-toolchain branch from C. Larson
* changes now upstream
* rebased my changes to the current oe-core trunk
* startet to setup a proper external layer at:
git://git.linaro.org/people/kwerner/meta-linaro.git
* got the minimal, sato and Qt image built again
(only two patches required on the oe-core tree)
Misc:
* remotely attended some Linaro Connect sessions
Regards,
Ken
The Linaro Toolchain Working Group is pleased to announce the release of
Linaro GDB 7.4 2012.02.
Linaro GDB 7.4 2012.02 is the first release in the 7.4 series. Based off
the latest GDB 7.4, it includes a number of ARM-focused bug fixes and
enhancements.
Interesting changes include:
* Update to GDB 7.4 code base.
* The "info proc" and "generate-core-file" commands will now also
work on remote targets connected to GDBserver on Linux.
The source tarball is available at:
https://launchpad.net/gdb-linaro/+milestone/7.4-2012.02
More information on Linaro GDB is available at:
https://launchpad.net/gdb-linaro
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
The Linaro Toolchain Working Group is pleased to announce the release of Linaro QEMU 2012-02.
Linaro QEMU 2012.02 is the latest monthly release of qemu-linaro. Based
off upstream (trunk) QEMU, it includes a number of ARM-focused bug fixes
and enhancements.
New in this month's release:
- A simplified A15 model (non-LPAE) which is sufficent to boot a
carefully-configured Linux kernel.
Known issues:
- Graphics do not work for OMAP3 based models (beagle, overo)
with 11.10 Linaro images.
The source tarball is available at:
https://launchpad.net/qemu-linaro/+milestone/2012.02
More information on Linaro QEMU is available at:
https://launchpad.net/qemu-linaro
The Linaro Toolchain Working Group is pleased to announce the 2012.02
release of Linaro GCC 4.6 and Linaro GCC 4.5.
Linaro GCC 4.6 2012.02 is the twelfth release in the 4.6 series. Based
off the latest GCC 4.6.2+svn183786, it contains a few bug
fixes and backports Cortex-A7 and Cortex-A15 support from FSF trunk.
Interesting changes include:
* Updates to 4.6.2+svn183786.
* Add initial Cortex-A7 support.
* Backport Cortex-A15 tuning improvements from upstream.
* Backport improvements to 64 bit unsigned comparisons.
Fixes:
* LP: #917967 Backport the fix for PR51799.
* LP: #836588 armel FTBFS with gcc 4.5 org 4.6 O2 and fPIC.
* LP: #879725 ICE in int_mode_for_mode, at stor-layout.c:490.
Linaro GCC 4.5 2012.02 is the eighteenth release in the 4.5 series. Based
off the latest GCC 4.5.3+svn183785, it is a maintenance only release.
Interesting changes include:
* Updates to 4.5.3+svn183785.
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.6-2012.02https://launchpad.net/gcc-linaro/+milestone/4.5-2012.02
Downloads are available from the Linaro GCC page on Launchpad:
https://launchpad.net/gcc-linaro
More information on the features and issues are available from the
release page:
https://launchpad.net/gcc-linaro/4.6/4.6-2012.02https://launchpad.net/gcc-linaro/4.5/4.5-2012.02
Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Bugs: https://bugs.launchpad.net/gcc-linaro/
Questions? https://ask.linaro.org/
Interested in commercial support? inquire at support at linaro.org
-- Ramana
Hi,
I'm doing some tricks with Linux kernel and I'm dependent on
bootloader atags passing.
On PandaBoard the u-boot is always passing DTF/Atags pointer in r2
register, and I'm kind of depending on it. I need to emulate this
behavior by -initrd qemu's argument. However it seems that
qemu-system-arm zeros the registers on the start, and places atags in
some hardcoded memory address no matter what.
Is this behaviour really OK? Isn't r2 register a proper way to pass
atags on ARM platform? If so, would you merge into mainline a patch
that implement this? I could write it, but I don't want end-users of
my work to have to patch and compile Qemu manually.
Please CC me, I'm not following actively these mailinglists.
Regards,
--
Dawid Ciężarkiewicz
Please take the time to comment on this mockup, would it be useful for you?
what other info you like to see to make your job easier, know what you have
on your plate, your WIs progress, what is next in priority ....
BR,
Mounir
---------- Forwarded message ----------
From: Guilherme Salgado <guilherme.salgado(a)linaro.org>
Date: Wed, Feb 1, 2012 at 9:54 AM
Subject: [RFC] Upcoming work view for individual engineers
To: linaro-dev(a)lists.linaro.org
Hi folks,
We're trying to make status.l.o more useful to engineers and the first
thing we're planning to do is a new page listing the upcoming work
assigned to a given person. I'm attaching a mockup of that view here and
we'd like to know what you think of it... Do you think that would be
useful to you? Is there any other information you'd like to see there,
or maybe a different way to present/group them?
Cheers,
--
Guilherme Salgado <https://launchpad.net/~salgado>
_______________________________________________
linaro-dev mailing list
linaro-dev(a)lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
--
Mounir Bsaibes
Project Manager
Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106http://twitter.com/#!/linaroorghttp://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>
Adjusted my 64-bit shifts patch to address Richard Earnshaw's concerns,
tested it, and posted the new one upstream.
Continued trying to figure out how ira-costs.c works, and in particular,
why it doesn't choose to do 64-bit stuff in NEON when I think it should.
Basically, the problem seems to be that when hard regs are *already*
assigned, prior to IRA (say because they are function parameters or
return values), then the allocator does not even consider the
possibility of moving that value to another register unless it
absolutely has to. It will merrily choose the worst possible option just
because it's the easiest decision.
Merged FSF GCC 4.5 into Linaro GCC 4.5. Likewise for 4.6. Pushed the
branches to Launchpad for testing. The 4.5 testing did not come back
totally clear, so this may delay the release a little. Hmmm.
Updated my FSF GCC 4.7 checkout and rebuilt it. This time the build
succeeded, so I've used it as the basis for a shiny new launchpad branch
"lp:gcc-linaro/4.7". I've created the release series to go with it.
Applied my new 64-bit shifts patch to the new GCC 4.7 Linaro branch and
submitted a merge request. This is mostly for the purposes of getting
the test results at this point.
Hi guys,
I compile a native gdb using linaro 2011.10 by “./configure
--host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi”, and
the gdb runs on arm target boards directly.
# gdb
GNU gdb (Linaro GDB) 7.3-2011.10
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-none-linux-gnueabi".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>.
(gdb)
I can use it to debug native programs on target boards directly. For
example, attach process, set breakpoints, check registers and memory.
One issue is I can't see multi-threads, for example:
PID 646 is system_server by ps
"646 1000 159m S system_server"
Then I use gdb to attach it:
# gdb attach 646
(gdb) info threads
Id Target Id Frame
* 1 process 646 "system_server" __ioctl ()
at bionic/libc/arch-arm/syscalls/__ioctl.S:15
as you see, “info threads” only shows one thread but there are several
threads in system_server.
But if I compile a new program based on glibc and gnu libthread, I can
see multi-threads by the gdb.
So my questions are:
1. Should I compile the native gdb using android toolchain and android
bionic/libthread libraries?
2. Why can’t the current gdb capture multithreads for android
processes? This question is actually about the theory for gdb to know
multi-threads. In my opinion, both gnu and android use clone() to fork
threads and threads in one process have same tgid in kernel and all
threads return same getpid() value. Why not gdb just travel process
lists to find multi-threads?
Thanks
Barry
Hi,
* Learned the basics of bzr and examined the gdb-linaro repository.
* Went through Michael Hope's steps to import upstream's 7.4 branch into
bzr.
* Explored gdb-linaro bugs and blueprints in Launchpad to familiarize
myself with what has been done
and is planned or proposed to be done.
* Went through the gdb-linaro/7.3 branch to verify what needs to be
forward-ported to gdb-linaro/7.4.
Forward-ported 10 patches.
* Checked which Linaro Connect sessions would be of interest for me to
attend remotely, but
found out that only one will be available for remote participation.
* Worked very little on Wednesday since my laptop refused to turn on
again after I hibernated it.
I found out on the next day that plugging in an external monitor makes
it happy again (I didn't
have a monitor on Wed to try this out so I was stuck). Apparently the
LCD screen died.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
Hi,
libunwind
* reviewed small patch from T. R. of Nokia who provided a bugfix
when searching for unwind table entry for an IP
OpenEmbedded
* build the OE-core images (minimal, sato and qt4e) with -O1 and -O0
* collected the ELF size and memory footprint and updated the charts
* encountered an issue when compiling Qt 4.8.0 using -O0. It causes
qdbusviewer fail to link
because an .LTHUNK symbol survives
* tested various compilers and optimization levels and
noticed that the .LTHUNK symbols do also survive with higher
optimization levels
* only the Linaro and ARM CSL toolchains seem to be affected
(FSF trunk, 46branch and 46release seem to work)
* provided a reduced testcase and opened lp #924726
* Linaro cc1 emits undefined label when using -fPIC -Os (lp #924889)
* already fixed upstream, Ramana is backporting to Linaro GCC
* look into the external-toolchain branch from C. Larson:
https://github.com/kergoth/oe-core/tree/external-toolchain
and tested it against CSL 2011.03 -> works fine
* started to document:
https://wiki.linaro.org/KenWerner/Sandbox/OpenEmbedded-Core
Regards,
Ken
== GCC ==
* Benchmarking the 4.6 backport of subreg forward-propagation
confirmed that this is a net loss. On 4.7, microbenchmarks
suggest a different outcome (due to register allocator
enhancements), so I've created a 4.7 Bazaar branch including
the patch and submitted it for benchmarking.
* Implemented a patch to allow memory operands with vec_set and
vec_extract to avoid excessive vmov generation in the PR 51819
test case. Patch shows no regression on microbenchmarks; full
testing and benchmarking still outstanding.
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:
Green:
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-02-20 || ||
||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04?||2012-02-01 ||
(for blueprint definitions: https://wiki.linaro.org/PeterMaydell/QemuKVM)
Historical Milestones:
||a15-usermode-support || 2011-11-10 || 2011-11-10 || 2011-10-27 ||
||upstream-omap3-cleanup || 2011-11-10 || 2011-12-15 || 2011-12-12 ||
||initial-a15-system-model || 2012-01-27 || 2012-01-27 || 2012-01-17 ||
== cp15-rework ==
* Since this isn't in the critical path any more we'll work on it
next quarter, and adjust its priority/due dates post Connect.
== qemu-kvm-getting-started ==
* finished writing up HowTo documents for reproducing the KVM
prototype and running it on a Fast Model:
https://wiki.linaro.org/PeterMaydell/KVM/HowTo
* did the last bits of testing enough to be able to say we've done
the initial prototype work for TCWG2011-A15-KVM, which means we
can close out the qemu-kvm-getting-started blueprint.
== other ==
* more upstream patch review, etc
* LP:926012: patches to support prctl(PR_SET_NAME, ...) in linux-user
mode, for the benefit of perl 5.14.
Summary:
* Analyze PATH issues for win32 binary toolchain.
Details:
1. Analyze PATH issues for win32 binary toolchain.
* gcc can not find the install dir if user set
PATH="INSTALL_DIR\bin" in dos cmdline, which leads to compile fail
since gcc can not find ../lib, ../libexec, etc.
* Root cause: in dos, " is taken as part of dirs during set PATH,
which is different from cygwin or linux. And dir with " is invalid in
dos.
* Work out a patch to filter " in function make_relative_prefix_1
and discuss it with Michael.
* Create an windows install package, so users do not need to set
PATH. Will discuss more detail with Michael for the following
releases.
2. Read document to ramp-up on gcc.
Plans:
* Feb 6-10: Linaro Connect Q1.12
Best regards!
-Zhenqiang
I've set up a new user on my laptop that we can use for experimenting
with benchmarks during Connect. Here's what we've got:
* A user called 'connect'
* Ramana, Ulrich, Åsa, and myself can log in via SSH
* bzr repo for trunk, 4.6, and gcc-linaro 4.6
* Tarballs of all gcc-linaro 4.4, 4.5, and 4.6 releases
* Tarballs of the recent CSL, Google 4.6, and Android 4.4 compilers
* A sysroot in ~/sysroot
* Cross-binutils etch in ~/cross
* A shared ccache in ~/ccache primed with these
* A ~/env.sh that sets up the right paths etc
* A ~/builds/doconfigure.sh that configures for our standard ARMv7-A
C/C++/Fortran configuration
* EEMBC, DENBench, and SPEC 2000 under ~/benchmarks
The trees under build/ build into build/$ver/build and install into
build/$ver/install.
The benchmarks are set up to cross build and cross run. I've pulled
ursa2 out of the farm and nuked it, so we can do something like:
make CROSS_COMPILE=arm-linux-gnueabi- RUN="$PWD/sshrun ursa2"
to run the benchmarks.
I'll see about perf. We still need to re-baseline the benchmarks and
get perf traces.
Anything else needed?
You can log in and try things if you want. Go through the bounce host
and try connecting as connect@crucis.
-- Michael
Hi Ramana,
as you pointed out, in the gcc.dg/vect/vect-double-reduc-6.c test case,
using compiler options as described in PR 51819, we see the following
inefficient code generation:
vmov.32 r2, d28[0] @ 57 vec_extractv4si [length = 4]
vmov.32 r1, d22[0] @ 84 vec_extractv4si [length = 4]
str r2, [r0, #4] @ 58 *thumb2_movsi_vfp/7 [length =
4]
vmov.32 r3, d0[0] @ 111 vec_extractv4si [length = 4]
str r1, [r0, #8] @ 85 *thumb2_movsi_vfp/7 [length =
4]
vst1.32 {d2[0]}, [r0:64] @ 31 neon_vst1_lanev4si
[length = 4]
str r3, [r0, #12] @ 112 *thumb2_movsi_vfp/7 [length =
4]
bx lr @ 120 *thumb2_return [length = 12]
(The :64 alignment in vst1.32 is incorrect; that is that actual problem in
PR 51819, which is now fixed.)
The reason for this particular code sequence turns out to be as follows:
The middle end tries to store the LSB vector lane to memory, and uses the
vec_extract named pattern to do so. This pattern currently only supports
an "s_register_operand" destination, and is implemented via vmov to a core
register. The contents of that register are then stored to memory. Now
why does any vst1 instruction show up? This is because combine is able to
merge the vec_extract back into the store pattern and ends up with a
pattern that matches neon_vst1_lanev4si. Note that the latter pattern is
actually intended to implement NEON built-ins (vst1_lane_... etc).
Now there seem to be two problems with this scenario:
First of all, the neon_vst1_lane<mode> patterns seem to be actually
incorrect on big-endian systems due to lane-numbering problems. As I
understand it, all NEON intrinsics are supposed to take lane numbers
according to the NEON ordering scheme, while the vec_select RTX pattern is
defined to take lane numbers according to the in-memory order. Those
disagree in the big-endian case. All other patterns implementing NEON
intrinsics therefore avoid using vec_select, and instead resort to using
special UNSPEC codes -- the sole exception to this happens to be
neon_vst1_lane<mode>. It would appear that this is actually incorrect, and
the pattern ought to use a UNSPEC_VST1_LANE unspec instead (that UNSPEC
code is already defined, but nowhere used).
Now if we make that change, then the above code sequence will contain no
vst1 any more. But in any case, expanding first into a vec_extract
followed by a store pattern, only to rely on combine to merge them back
together, is a suboptimal approach. One obvious drawback is that the
auto-inc-dec pass runs before reload, and therefore only sees plain stores
-- with no reason whatsoever to attempt to introduce post-inc operations.
Also, just in general it normally works out best to allow the final choice
between register and memory operands to be make in reload ...
Therefore, I think the vec_extract patterns ought to support *both*
register and memory destination operands, and implement those via vmov or
vst1 in final code generation, as appropriate. This means that we can make
the choice in reload, guided as usual by alternative ordering and/or
penalties -- for example, we can choose to reload the address and still use
vst1 over reloading the contents to a core register and then using an
offsetted store.
Finally, this sequence will also allow the auto-inc-dec pass to do a better
job. The current in-tree pass doesn't manage unfortunately, but with
Richard's proposed replacement, assisted by a tweak to the cost function to
make sure the (future) address reload is "priced in" correctly, I'm now
seeing what appears to be the optimal code sequence:
vst1.32 {d6[0]}, [r0:64]! @ 30 vec_extractv4si/1
[length = 4]
vst1.32 {d22[0]}, [r0]! @ 56 vec_extractv4si/1 [length =
4]
vst1.32 {d2[0]}, [r0:64]! @ 82 vec_extractv4si/1
[length = 4]
vst1.32 {d4[0]}, [r0] @ 108 vec_extractv4si/1 [length =
4]
bx lr @ 116 *thumb2_return [length = 12]
(Again the :64 is wrong; it's already fixed on mainline but I haven't
pulled that change in yet.)
The attached patch implements the above-mentioned changes. Any comments?
I'll try to get some performance numbers as well before moving forward with
the patch ...
(As an aside, it might likewise be helpful to update the vec_set patterns
to allow for memory operands, implemented via vld1.)
(See attached file: diff-gcc-arm-vecextractmem)
B.t.w. I'm wondering how I can properly test:
- that the NEON intrinsics still work
- that everything works on big-endian
Any suggestions would be appreciated!
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
Hi Andrew. gcc-4.7~svn183693 just finished running through the auto
builders and builds and tests in the ARM, Cortex-A9, i686, and x86_64
configurations.
You could base the Linaro 4.7 branch off that. It's r114897 in bzr
and, suitably, Sandra is the author.
-- Michael
For your records:
Loïc wrote a script that pushes the revisions from a GCC branch into
the current development focus. This makes branching on a shared
repository much faster. The script is here:
http://bazaar.launchpad.net/~linaro-toolchain-dev/cbuild/tools/view/head:/e…
and it runs daily on a cronjob as the cbuild user on the 'apus' EC2
instance (phew).
We'll need to update this when 4.7 comes along.
-- Michael
I've gone through the documentation on the wiki about how to get
going with KVM on Fast Models, to clean it up and reorganise it
and add some of the missing bits (notably how to set up a KVM
guest kernel and filesystem). It's now at:
https://wiki.linaro.org/PeterMaydell/KVM/HowTo
The only minor point I'd still like to address is that at the
moment we document the old-style "build your kernel and arguments
into an .axf file" boot-wrapper, because my changes to support
specifying them at model runtime haven't yet gone into the
boot-wrapper git repo. When they do land I'll update the wiki.
(Yes, technically TCWG2011-A15-KVM says "one page summary" but
I thought splitting it into four pages was much clearer :-))
-- PMM
Ken, Åsa: could you add a -O0 and -O1 build to the size and benchmark
results? I'm looking at the writeup and it would be interesting to
contrast the speed/size of -O0 with -O2.
Ta,
-- Michael
Continued work on 64-bit shifts in core registers. This has now been
posted to gcc-patches, and is awaiting review.
64-bit shifts in NEON are also working correctly, but the register
allocator chooses not to use them most of the time. I've begun trying to
work out why, but it's quite involved in ira-costs.c and will take some
unpicking, I think.
Attempted to create a Linaro GCC 4.7 branch, but my test build failed,
so that'll have to wait until it's stabilized a little.
