This is my current 4.7 auto-inc-dec.c patch. I submitted an RFC in July:
http://article.gmane.org/gmane.comp.gcc.patches/241779/
and updated the patch in line with the feedback I got. Steven Bosscher
sent some very useful comments in private email, so the update deals
with those as well as Bernd's public ones.
If we do go ahead with this rewrite, it depends on the A9 pipeline
description changes. I submitted some A8 and A9 changes here:
http://article.gmane.org/gmane.comp.gcc.patches/244238/http://article.gmane.org/gmane.comp.gcc.patches/244242/
but because I later noticed that the A9 didn't behave quite as I thought,
I decided not to apply them. Ramana asked around internally about what
the A9 actually does (thanks) and had some ideas.
The patch also relies on the MEM rtx_costs patch that I just posted:
http://lists.linaro.org/pipermail/linaro-toolchain/2011-December/001944.html
Richard
gcc/
* Makefile.in (auto-inc-dec.o): Depends on $(OPTABS_H) and
addresses.h.
* auto-inc-dec.c: Rewrite.
Index: gcc/Makefile.in
===================================================================
--- gcc/Makefile.in 2011-12-07 11:43:29.549238252 +0000
+++ gcc/Makefile.in 2011-12-29 09:24:51.066303201 +0000
@@ -3145,7 +3145,8 @@ alloc-pool.o : alloc-pool.c $(CONFIG_H)
auto-inc-dec.o : auto-inc-dec.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \
$(TREE_H) $(RTL_H) $(TM_P_H) hard-reg-set.h $(BASIC_BLOCK_H) insn-config.h \
$(REGS_H) $(FLAGS_H) output.h $(FUNCTION_H) $(EXCEPT_H) $(DIAGNOSTIC_CORE_H) $(RECOG_H) \
- $(EXPR_H) $(TIMEVAR_H) $(TREE_PASS_H) $(DF_H) $(DBGCNT_H) $(TARGET_H)
+ $(EXPR_H) $(TIMEVAR_H) $(TREE_PASS_H) $(DF_H) $(DBGCNT_H) $(TARGET_H) \
+ $(OPTABS_H) addresses.h
cfg.o : cfg.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(RTL_H) $(FLAGS_H) \
$(REGS_H) hard-reg-set.h output.h $(DIAGNOSTIC_CORE_H) $(FUNCTION_H) $(EXCEPT_H) $(GGC_H) \
$(TM_P_H) $(TIMEVAR_H) $(OBSTACK_H) $(TREE_H) alloc-pool.h \
Hi,
Thank you all for an interesting and pleasant experience. I am very
grateful to Linaro for the opportunity to meet and work with such an
amazing group of people. I wish you all the best, and hope to meet you
again (at least online).
You can find me at irar(a)il.ibm.com or ira.rsn(a)gmail.com.
Ira
Summary:
* Read armV7-A/R reference manual; crosstool-ng patches and wrapper scripts.
Details:
1. Patches for crosstool-ng:
* Fix symlink issue when CT_USE_SYSROOT is not enabled.
* Update sample/linaro-arm-none-eabi (baremetal) to disable
SYSROOT. So that both include and lib files are in the same dir.
2. Study armV7-A/R reference manual.
3. Validate embedded toolchain Dec. release.
4. Enhance the wrapper to use crosstool-ng for embedded toolchain.
Plan:
* Ramp-up on gcc.
Best regards!
-Zhenqiang
Submitting patch for Bug #879725:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01459.html
Looking at the performance results running SMS with automatic testing.
This is my last week in Linaro so I would also like to thank you all
for the interesting year -- it was a great experience for me to work
in this project. I wish you all good luck and happy holidays!
Revital
Hi,
OpenEmbedded-Core:
* No response on the CSL patches I posted to the ml yet
* khem says someone (other than me) needs to try them
* Linaro binary toolchain
* Runs on Oneiric-X86_64 after installing lsb-core
(interpreter: /lib/ld-lsb.so.3)
* The do_rootfs tasks fails with runtine dependecy issues when
using the external-linaro-toolchain_arm-2011.11.bb recipe.
When re-using my CSL 2011.03 recipe with the linaro toolchain
the error doesn't show up - strange.
* OE-Core build gets confused by the (arm-linux-gnueabi-)pkg-config
of the external linaro toolchain. As a workaround I just renamed
this script.
* The qemuarm MACHINE configuration uses "-march=armv5te -mno-thumb"
Since the linaro toolchain defaults to thumb and -mno-thumb has no
effect some inline assemblies are failing (i.e. on the umull insn).
GNU #47930 suggests using -marm instead -> OE-Core patch posted.
* Got the core-image-minimal to build, but it doesn't run yet
(I suspect some basic runtime dependencies like libc again)
* The build of the sato image fails
(seems libtool and/or C++ related - need to investigate)
Regards
Ken
Hi,
* Continued with comparison of eembc results for gcc4.4 and gcc 4.6 (FSF
and Linaro). Collecting results for 4.6 with loop-unrolling turned off.
* Working on a plotbench.py script that will use matplotlib for plotting
the results. Right now the script plots the geomean value, for instance for
eembc. I now try to make it plot all subtest as well. Then it should also
show relative improvements instead of just the numbers, and then also
sorted from best to worse. This script depends on Michaels script
libtabulate.py for transforming the tabulated file back to python records.
* Will be back January 9
/Regards
Åsa
== GDB ==
* Ongoing work on remote support for "info proc" and core file
generation. Completed implementation of latest solution
via accessing arbitrary files on the remote site, only to
run into a fundamental design problem ... so it's probably
back to the previous approach. Discussion on the list is
ongoing.
* Fixed a GDB 7.4 test suite failure on ARM: PR tdep/12797
* Fixed another GBD 7.4 test suite failure on ARM, by enabling
pthread_t thread debugging on core files.
== 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
Hi there. I've looked further into the intermittent
gcc/testsuite/g++.dg/cdce3.C test failures. Taking Ira's
vectoriser-only fix-pr51301-4.6 branch and comparing it with it's
predecessor r106845:
* cdce3.o itself is identical across compilers
* Fault occurs in a parallel test run as part of the normal auto build
* Fault occurs every time
* Fault occurs with a manual 'make check-gcc RUNTESTFLAGS="dg.exp=cdce*'
* Fault doesn't occur when building from the command line
* Fault doesn't occur after updating binutils
I'm suspicious of the linker. The auto builders are Natty based and
come with ld 2.21.0.20110327. Updating them to Oneiric's
2.21.53.20110810 clears the problem.
I've saved the build trees. I see no reason not to commit
~ramana/gcc-linaro/fix-lp-900426 and ~irar/gcc-linaro/fix-pr51301-4.6.
-- Michael
== GDB ==
* Ongoing work on remote support for "info proc" and core file
generation. Implemented initial version of latest solution
via accessing arbitrary files on the remote site.
== GCC ==
* Started familiarizing myself with current status of various
performance patches in programm, in preparation of my taking
on GCC performance work next year.
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