== GCC ==
* Completed testing and benchmarking of patch to use vld1/vstd1
instead of vldm/vstdm for vector moves. Saw no regressions but
only minor benefits.
* Checked in patch to fix LP #959242 (GCC PR tree-optimization/52633)
to FSF mainline and 4.7 branch; backports to Linaro GCC 4.7 and 4.6
pending.
* Checked in mainline patch to enable -fsched-pressure by default
on s390.
* Ongoing work on improving end-of-loop value computation.
* Started investigation of TSVC vectorizer test kernels.
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 Uli,
While looking into something else I ran into these - I wonder how many
of these GCC manages to vectorize ...
http://www.netlib.org/benchmark/livermorec . These look interesting
from a vectorizer kernels point of view.
The other interesting paper of note was this PACT paper on
vectorization benchmarks comparing icc , xlc and GCC which might
provide some interesting hints / reading.
http://polaris.cs.uiuc.edu/~garzaran/doc/pact11.pdf . The appropriate
benchmarks kernels are linked to below.
http://polaris.cs.uiuc.edu/ ̃maleki1/TSVC.tar.gz.
regards,
Ramana
I've put the agenda for Monday's call at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2012-05-07
which is:
* Review action items from last meeting
* Connect sessions:
* GDB for Android
* GCC performance call - Live!
* KVM performance
* Renderscript
* Android benchmarking
* Dalvik improvements
* Hard float switchover status
* multiarch upstreaming
* Next week is release week
* vld1, EEMBC results, and noise
* twolf result variance
* KVM minimum features
* UP/UP, Ubuntu
* [[MichaelHope/Sandbox/KVMUseCase]]
Feel free to edit,
-- Michael
I've done some minor updates to the instructions for working with
gcc-linaro, bzr, and merge requests at:
https://wiki.linaro.org/WorkingGroups/ToolChain/BzrTips
The interesting changes are using:
* bzr commit --fixes=lp:nnnn to link a branch to a bug number
* bzr branch --hardlink to cut down on branch time and disk usage
* bzr-merge-changelog to automatically merge ChangeLog.linaro
-- Michael
Greetings,
I successfully built BusyBox using the 4.5.2 toolchain. When I try to build BusyBox using the same config with the 4.6.3 toolchain I get the following error:
The Linaro 4.5.2 toolchain was installed in my Ubuntu 11.04 distro using aptitude.
The Linaro 4.6.3 toolchain binaries, downloaded via Launchpad, were installed into my own tools directory.
busybox # make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
scripts/kconfig/conf -s Config.in
can't find file Config.in
make[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2
make: *** [include/autoconf.h] Error 2
I get the same error if I try 'make oldconfig' or 'make menuconfig'.
Is there a PATH I need to set? Am I missing a package?
Right now my PATH has following 4.6.3 directories set:
linaro-4.6.3/bin
linaro-4.6.3/arm-linux-gnueabi/libc/usr/include
linaro-4.6.3/arm-linux-gnueabi/libc/lib/arm-linux-gnueabi
linaro-4.6.3/arm-linux-gnueabi/libc/usr/include
Thanks,
Dan
I thought I'd send an update on the SPEC 2000 twolf variance. We're
seeing a high amount of variance in the results for the SPEC 2000
twolf, vpr, and galgel benchmarks. I've run tests on a PandaBoard,
Origen, and IGEPv2 and gotten a coefficent of variance of 0.014,
0.017, and 0.003 which suggests that the problem is Cortex-A9
specific. twolf is hard on the cache so my theory is that it's
something to do with the memory subsystem. I currently have a
PandaBoard running with SMP, heap randomisation, virtual address
randomisation, and the branch predictor off and the CPU down clocked
to the non-overdrive 600 MHz. I'll let this run overnight and see if
the results are tighter.
To solve Andrew's immediate problem, I'm running SPEC on the 64 bit
core register shifts on the OMAP3. The results are tight enough that
we should be able to show any regressions.
-- Michael
I added Ubuntu 12.04 'precise' based sysroots to Jenkins yesterday. They
are built using 'armhf' architecture and available in three flavours:
- alip
- nano
- ubuntu-desktop
So far only -dev ones are present, will work on -dbg ones soon.
We have 'nano' one built and available to fetch at
http://snapshots.linaro.org/precise/images/nano-dev/ - rest will be
built when there will be machine free to do that.
They will also be moved to http://snapshots.linaro.org/precise/sysroots/
to not make people try to boot them ;)
Please take a look do they work as you want and tell me what kind of
changes you would like to have, which images are not needed, which
should be added. Are there any users for -dbg style sysroots?
I did see gcc-4.7 fail to build for an sf/hf multilib configuration. The reason
was that gcc -print-multi-directory didn't print anything for the non-default,
and gcc -print-multi-lib only prints `.'. The reason is that set_multilib_dir
in gcc.c only consults MULTILIB_DEFAULTS (only defined in linux-elf.h), but not
the default configure options in configargs.h. This proposed patch updates
MULTILIB_DEFAULTS depending on the configure options. An alternative approach
would be to update set_multilib_dir and print_multilib_info to lookup the
configure_default_options in configargs.h as well.
Note that this didn't fail to build in gcc-4.6, but I can't see yet what change
did cause the build failure.
Matthias
* Linaro
Continued looking at the lower-subreg problem (that the lowering is only
really intended for 32-bit targets that don't have 64-bit operation).
Without NEON this is only really a problem for "ldrd/strd" 64-bit loads
and stores: the patterns are all (or should be all) written such that
they only access DImode regs via SUBREG, so it all works well. When
adding NEON 64-bit this becomes less clear: many operations must remain
in DImode without SUBREG until after register allocation. The
lower-subreg passes mostly cope with this well enough, but it has some
features that attempt to lower zero_extends, certain shifts, and
pseudo-reg copies, unconditionally. I've been investigating what happens
if I disable the pseudo-reg copy "optimization" in the first
lower-subreg pass. As I expected, in many cases it actually leads to
smaller code (more use of LDRD/STRD) without NEON, and even better
results with NEON. Unfortunately I have found so counter-examples, so
I'm trying to figure out what's going on there: for some reason reload
goes crazy and starts spilling things to the stack, even though I can't
see that more registers are required. More investigation required.
Richard E approved my NEON-immediates patch for upstream. I don't have
time to commit it with proper care this week, so that's delayed to next
week.
* Other
Vacation Monday and Tuesday. Had a fun long weekend in Cornwall with my
family.
