[ACTIVITY] 22nd - 28th November
Reviewed Yao's patch for AND optimization. Some back on forth on the best way to tackle this problem. LP:663939 - thumb2 constant loading - backported my patches to GCC 4.5 - awaiting review LP:595479 - .eh_frame broken. - Discovered this problem had been fixed (with Thomas' patch) since August, and has also been fixed upstream, albeit with an alternative patch. Nothing to do here. LP:641379 - bitfields poorly optimized. - analysed the problem. The code in cse.c that is supposed to fix this does not recognise the case. - created a patch and tested it for both GCC 4.6 and 4.5. - awaiting review LP:674146 - dpkg segfault. - started looking at this, but Chung-Lin took it first. While trying to reproduce lp:674146, I discovered that my IGEPv2 had a corrupted rootfs, again. I only fixed it last week, so I looked into it more deeply. It seems the SD card has developed at least one bad block. Reformatted, scanned and reinstalled the files from backup. I think the problem was caused by the daily apt package download (it was always those files that were corrupt), so I've disabled that. I've also disabled access-time-stamps. If it happens again I will have to consider using a different underlying filesystem format. LP:643479 / CS Issue:8610 - Multiply and accumulate optimization - created patches for both issues. - both were machine description subtleties. - backported the patches to 4.5 - the patches apply and work fine, but ... - found an extra problem with redundant moves - awaiting review GCC 4.6 - Created a new Launchpad series and branch to track GCC 4.6 development. - Set up the CS internal build config. - Tried to build the latest checkout and failed - glibc problem still unfixed - Jie has reported it now. - libquadmath build fails Merged FSF GCC trunk (pre-4.5.2) into Linaro GCC 4.5 tree. Merged the outstanding Launchpad merge requests into GCC 4.5. The testing showed regressions, so I backed out most of the merges and did them in smaller batches. Chung-Lin and Richard's patches passed the testing, so that leaves Yao's as the problem patch. I didn't get time to test this assertion this week. -- Next week: Vacation. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
New data centre host
Hi there. Our Versatile Express has been installed in the data centre and is available for use. See: https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware for the details. If you're a member of the Toolchain WG then you should already have an account. Dave is currently using this machine for benchmarking. Until we get more hardware, please use IRC or email to manage access. -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: GCC Optimization Brain Storming Session
On Sat, Nov 27, 2010 at 12:11 AM, Andrew Stubbs wrote: > Hi All, > > As we discussed on Monday, I think it might be helpful to get a number of > knowledgeable people together on a call to discuss GCC optimization > opportunities. > > So, I'd like to get some idea of who would like to attend, and we'll try to > find a slot we can all make. I'm on vacation next week, so I expect it'll be > in two or three week's time. 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/gcc-linaro/+spec/armv6-simd) Using ARMv7 unaligned accesses (https://blueprints.launchpad.net/gcc-linaro/+spec/unaligned-accesses) Changing the built-in memcpy to use unaligned (https://blueprints.launchpad.net/gcc-linaro/+spec/unaligned-memcpy) The following areas have been suggested. I don't know if they're still valid: Register allocator: The register allocator is designed around the needs of architectures with a low register count and restrictive register classes. The ARM architecture has many general purpose registers. Different assumptions may give better code. Conditional instructions: The ARM and, to a lesser extent, Thumb-2 ISAs allow conditional execution of instructions. This can be used in many situations to eliminate an expensive branch. The middle end expands and transforms branches. The ARM backend tries to recombine the RTL back into conditional instructions, but often can't due to the middle end transforms. -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 22nd -- 28th Nov.
== Linaro GCC ==
* LP:634738: Firstly, fix this in combiner. Try the other approach
(without changes to arm.md) suggested by Andrew S, to fix
arm_gen_constant in some cases to generate lsl/lsr ranther loading
constant. Some piece of code in arm.c was written in 1998, hard to
understand with few comments. During this, find some lsl/lsr can be
replaced by ubfx. Use gen_extzv_t2 when arm_arch_thumb2 is true to
transform lsl + lsr to ubfx. Two patches are ready.
* LP:633243: Got build failures on FSF trunk for
arm-none-linux-gnueabi. Test patch on FSF trunk 2010-10-21. No regression.
* LP:638935: predicate "vfp_register_operand" should return true for
VFP_D0_D7_REGS registers. Fixed.
predicates {store,load}_multiple_operation assumes mode is SImode, and
size of data is 4. Fix them to accept multiple VFP operations. Write
three new test cases for stm/fldm/fstm pattern. Test patch on FSF trunk
2010-10-21. No regression.
* SMS on thumb2. Discussed with Revital Eres back and forth on doloop
pattern for thumb2. doloop pattern is not recognized so far on thumb2.
Revital has a fix to thumb2_cbz pattern. After this fix, doloop
pattern should be recognized.
* Ping ARM fix PR45701 in gcc-patches for the fifth time. Still no reply.
== This Week ==
* Look at regressions of ldm/stm backport on Linaro GCC 4.5.
* Internal review of patch to LP:638935
* Try SMS on thumb2 for EEMBC, if Revital's thumb2_cbz pattern fix is
accepted by upstreams.
--
Yao (齐尧)
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Nov. 22 -- Nov. 28
== Last Week ==
* Started writing libunwind support for ARM-specific unwinding, but
realized that the native ARM toolchain may be causing problems. Spent time
trying to isolate the issues, but haven't found the culprit yet.
* Began to consider the possibility of developing an ARM-specific
unwinding library which would integrate into libunwind (and be reusable
elsewhere). Basically, the ARM.ex{idx,tbl} sections are unique to ARM.
* Looked at other applications where unwinding functionality already
exists to see how ARM unwinding is done (e.g. GDB).
Could/should that functionality be replaced with calls to libunwind (or
to the aforementioned ARM-specific helper library)?
== This Week ==
* Continue to implement ARM-specific unwinding in libunwind.
--
Zach Welch
CodeSourcery
zwe...@codesourcery.com
(650) 331-3385 x743
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Nov.22 -- Nov.28
== Linaro and upstream GCC == * LP #674146, dpkg segfaults during debootstrap on natty armel: analyzed and found this should be a case of PR44768, backported mainline revision 161947 to fix this. * LP #641379, bitfields poorly optimized. Discussed some with Andrew Stubbs. * GCC bugzilla PR45416: Code generation regression on ARM. Been looking at this regression, that started from the expand from SSA changes since 4.5-experimental. The problem seems to be TER not properly being substituted during expand (compared to prior "convert to GENERIC then expand"). I now have a patch for this, which fixes the PR's testcase, but when testing current upstream trunk, hit an assert fail ICE on several testcases in the alias-oracle; it does however, test without regressions on a 4.5 based compiler. I am still looking at the upstream failures. == This week == * Continue with GCC issues and PRs. * Think about GCC performance opportunities (Linaro) ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
