Hi,
Now that upstream trunk is in stage3 and we have a few patches that
won't really make it upstream until stage1 is reopened is it
worthwhile having a new status in the merge requests that moves it
into a to_upstream status . The other option is to have a common
spreadsheet that we keep updating with links to merge requests that
need to be upstreamed .
Thoughts ?
Ramana
PS - Any clue on what's happening with the branch diff bug that's been
open in launchpad forever now ?
Hi,
* Worked on peeling problem in eon (#831094). Wrote a patch that
checks if the number of vector iterations is going to be more than 2,
and disables peeling otherwise. With this patch I see about 1.5%
regression with vectorization (and about 7% without it).
* I am thinking to extend the patch for unknown number of iterations
by creating a run-time check. The threshold could be set by param.
Another option, could be doing it through the cost model, but it's
hard to evaluate costs when misalignments are unknown (and, I think,
the cost model handles known misalignment properly).
* Disabling peeling for low loop bounds also helps with one of EEMBC
benchmarks, for which vectorization with double-words is more
beneficial than with quad-words. It turns out that we are able to
force the alignment for double-words (and, therefore, avoid peeling),
because we check that the required alignment (64 in this case) is less
or equal to BIGGEST_ALIGNMENT, where
arm.h:#define BIGGEST_ALIGNMENT (ARM_DOUBLEWORD_ALIGN ?
DOUBLEWORD_ALIGNMENT : 32)
and
arm.h:#define DOUBLEWORD_ALIGNMENT 64
So, we can never force alignment for 128 bits on ARM. I wonder if
that's a real limitation.
* Proposed three SLP patches to gcc-linaro, and merged two of them.
Ira
Addressing the comments received from Richard and Ayal regarding the
patch to estimate register pressure.
Testing the patch on eembc and libav micro benchmarks.
Looking at the regressions seen with SMS.
== GDB ==
* Ongoing work on support for cross-platform core file generation.
Posted a new design proposal to the mailing list to include not
only "info proc mappings", but *all* "info proc" commands. This
would involve a remote protocol command to read arbitrary proc
files, instead of a specific command to retrieve the memory map.
* Investigated Launchpad bug:
#891970 msp430-gdb segmentation fault with target remote
== 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
Worked on adding support for 64-bit NEON integer shifts. I have this
working now, although I'm still not very happy about how the register
allocator chooses which mode to use - it prefers core-registers if the
values start or end in core-regs, even though moving to values to NEON
registers might be more efficient (general 64-bit shifts in core
registers require several instructions). I've also had to mark the CC
register clobbered in all cases, even though it only gets clobbered in
some of them, which might be necessary, but isn't very satisfactory.
The NEON shifts work showed that 32->64 bit extends could be done better
also. This hasn't been a great problem up to now, but the shift amount
(in particular) is typically a 32-bit value and yet needs to be
zero-extended to 64-bit for NEON's purposes. Right now, GCC prefers to
extend the value in core-registers, and then copy it to NEON. This
works, but burns another core-register - a scarce commodity - so I think
it would be better to copy it first, and then extend it after. NEON has
instructions for this, so I'm investigating how to get the compiler to
do it (this is all strictly post-combine, so the usual options are out,
and the register allocator has to be allowed to do it the old way in the
case where core-regs really are the best option, so it's tricky).
Summary:
* Upstream crosstool-ng patches.
* Create windows install package from installjammer.
* Investigate link issues.
Details:
* crosstool-ng patches.
* Patches for newlib extra config, gdb extra config, pch, nls option
are committed to crosstool-NG upstream.
* The dependant library patches are in discussion.
* Learn installjammer and integrate it to scripts to create windows
install package.
* Investigate warning message from link when linking the prebuilt zlib
for migw32 host.
It might be OK with static link, but migh fail with dynamic link on windows.
For i586-mingw32[msvc] host, lots of messages like
libtool: link: Could not determine host path corresponding to ...
For i386-mingw32 host: In addition to the message in i586-mingw32
build, output the following message
*** Warning: linker path does not have real file for library -lz. ...
Plans:
* Build and test.
Absences:
* Nov 29, 30: Trainings.
Thanks!
-Zhenqiang
Hi,
Good news -- I just built a version of ICS with the current version of
linaro-gcc.
Panda build here:
http://people.linaro.org/~bernhardrosenkranzer/boot.tar.bz2http://people.linaro.org/~bernhardrosenkranzer/system.tar.bz2http://people.linaro.org/~bernhardrosenkranzer/userdata.tar.bz2
Use linaro-android-media-create as usual to install.
This is not yet a build that we can reproduce inside android-build
because I've had to cheat by swapping out linkers in a couple of
places (just using current binutils the way we normally do produces a
build that doesn't boot, using binutils built from the AOSP source
release works, but the prehistoric linker doesn't know about "dmb st",
can't link u-boot, can't link the kernel, and strangely enough can't
link some components of ICS - apparently the binaries they ship have
some extra patches in).
But the good news is that every part is built with our compiler -
there's nothing in the way of using that (aside from the code
insanities I've already fixed).
I'll work on sorting out binutils now...
ttyl
bero
Hi,
I've spent most of my time to dig into OE. First I started with OE
(classic); then realized that OE-core is where the future happens and
switched to it. I've set up a build system and got a ARM minimal image
to build that boots in QEMU *yay*. In parallel I've been reading the
manual and looked into the receipts to find out what toolchain they are
using (gcc-4_6-branch plus patches). Next step is to get the OE-core
built using the Linaro-GCC.
Regards
Ken
== This week ==
* Looked at the MIPS _unpack_d bug. libgcc.a did have a definition,
and Michael couldn't reproduce with his build, so the bug report
is now marked as Incomplete.
* Backported patch for PR 48190 to upstream 4.6 and 4.5.
* Reviewed Revital's SMS register-pressure patch.
* More on -fsched-pressure. I now have a version that I'm happy with
as far as ARM goes, in that it usually seems to produce code that is
no worse than the better of currect -fsched-pressure and current
-fno-sched-pressure. (I'm sure there's a better way of saying that.)
In some cases it is better than both.
* Continued trying to catch up on mail.
== Next week ==
* Clean up the -fsched-pressure code (it's still in its "experimental mess"
state). Try it on Power.
* Resurrect vzip and vunzp patch after Richard E said he wouldn't object.
Richard
