Re: Thumb2 code size improvements

This reminds me of a PR that Bernd did: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40657 It is also support for adding the r0-r3 registers to the epilogue/prologue push-pop for sake of reducing code size, though in a sense even more aggressive; it tries to merge the local stack allocation SP s

binutils testsuite Thumb-2 coverage

Hi, about the status of binutils testsuite Thumb coverage (CS204 in the workplan), I have filed two Launchpad bugs: #640263: Testsuite coverage: Thumb-2 VFP/NEON encodings https://bugs.launchpad.net/binutils-linaro/+bug/640263 #640272: Testsuite coverage: Thumb relocations https://bugs.launchpad

Re: Help on merging two patches

Yao Qi wrote: 6801 ldr r1, [r0, #0] f831 3013 ldrh.w r3, [r1, r3, lsl #1] -f413 6f00 tst.w r3, #2048 ; 0x800 -f43f af41 beq.w cc +0518 lsls r0, r3, #20 +f57f af44 bpl.w cc 4610 mov r0, r2 Someone suggests that the slowdown might be caused by usage of r0 in first instruction. Since r0 is used

Re: Upstream GCC feature freeze

On 2010/11/8 下午 07:01, Andrew Stubbs wrote: Here's my proposal: * Create a new Launchpad branch for GCC 4.6. * Synchronize this branch with upstream regularly * once per week, perhaps. * Try to get upstream approval for all new patches in the usual way * on the understanding that

[ACTIVITY] Nov.15 -- Nov.21

== Linaro and upstream GCC == * Linaro launchpad issues: - LP #672833, x64-64 varargs regression: after testing pushed bzr branch for merging. - LP #634738, inefficient low bit extraction: some discussion with Yao. - LP #618684, ICE when building ziproxy: looked into and quickly found not repro

[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 PR454

Re: A question about thumb2 cbnz/cbz implementation in thumb2.md

Unfortunately, cbnz/cbz has a 6-bit:'0' (7-bit aligned to 2) immediate offset that is *zero extended*, i.e. it is only for forward branches. Chung-Lin On 2010/11/29 下午 04:14, Revital1 Eres wrote: Hello, I have a question about cbnz/cbz thumb-2 instruction implementation in thumb2.md file: I

Re: A question about thumb2 cbnz/cbz implementation in thumb2.md

is instruction + 4-130). http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001l/QRC0001_UAL.pdf Thanks, Revital From: Chung-Lin Tang To: Revital1 Eres/Haifa/i...@ibmil Cc: linaro-toolchain@lists.linaro.org Date: 29/11/2010 10:21 AM Subject:Re: A question about thumb2 cbnz/cbz impleme

[ACTIVITY] Nov.29 -- Dec.05

== GCC related == * PR44557, Thumb-1 ICE: originally thought a fix of constraint will work, however after simplifying the testcase, received another ICE in postreload, due to a load of IP, which is not permitted in Thumb-1. Looking at some reload internals as part of fixing this. * PR45416, A

[ACTIVITY] Dec.6th -- Dec.12th

== GCC related == * PR44557, Thumb-1 ICE: found two small needed corrections in the ARM backend to fix this. Sent patch upstream. * LP:641397/PR46888: bitfield insert optimization. Posted patch along with Andrew Stubbs' CSE patch upstream. The two-patch situation seemed to stir some discussio

[ACTIVITY] Dec.13 -- Dec.19

== GCC related == * CS Issue #10201 / PR46883, unrecognizable insn ICE when compiling Samba. Fixed this by changing the predicates of two split patterns. Patch reviewed in CS internally and upstream, committed upstream, will backport to SG++ and Linaro soon. * LP:641397/PR46888: bitfield insert op

[ACTIVITY] Dec.20 -- Dec.26

== GCC related == * Launchpad #693686, GCC ARM segfault ICE when building Chromium in V8. Spent some time reproducing; this ICE seems to be in the maverick gcc-4.5, at the vectorizer phase. As the ICE happens in tree-vect-stmts.c:supportable_widening_operation(), I'm suspecting (without further ver

[ACTIVITY] Dec.27 -- Jan.02

== GCC issues == * PR44557, Thumb-1 ICE, looked at the ARM specific secondary reload parts, as well as some general reload internals context. Concluded that concerns on Thumb-2 about my submitted patch should be unneeded, as the reload_in/out patterns should never be used for Thumb-2. Also looked a

[ACTIVITY] Jan.3 -- Jan.9

== Last week == * Some discussion about libffi variadic function support. The current proposed design is an additional API function to prepare a new call interface (CIF) structure with the argument number settings for each variadic call site. This IMHO, is slightly less flexible that doing a call-t

Re: Bug fixes for -Os issues in GCC 4.5.x in Linaro?

On 2011/1/25 04:22, Wolfgang Denk wrote: > Hello, > > could you please provide some comments about the state of "-Os" > (optimising for size) in the gcc 4.5.x versions of Linaro's tool > chain? > > It appears there are a number of issues with recent versions of GCC > that get triggered when optim

[ACTIVITY] Jan 24--30

== Last week == * PR47246, VFP index range on Thumb-2. Submitted and committed patch upstream. * Pinged two upstream submissions on gcc-patches, one for PR44557 and the other a patch for LP:689887; still awaiting approval. == This week == * Chinese New Year Holiday, I'll be off until Feb.8th. __

[ACTIVITY] Jan 31 -- Feb 13

== Week of Jan.31st--Feb.6th == * Vacation, Chinese New Year Holiday. == Last week == * Monday (Feb.7th), last day of vacation. * LP #711819, ICE in push_minipool_fix: this turned out to be a simple case where a memory load alternative was not tagged with the minipool range attributes. Patch sent

[ACTIVITY] Feb 14 -- Feb 20

== Last week == * PR46178, PR46002: both upstream issues related to the priority coloring mode of IRA. Both patches submitted, the first already approved and committed. Vladimir M. did mention that the priority algorithm would be removed once his newer "cover class-less" patches goes in during sta

[ACTIVITY] Feb 21 -- Feb 27

== Last week == * Launchpad #721021 GCC ICE on ARM/XScale: identified as case of upstream PR45177; backported and pushed to Linaro. * Launchpad #709453/CS Issue #7122: Neon vmov 0.0 issues; some progress on my current WIP patch, but tests showed another 3 regressions, still on-going. * Launchpad

[ACTIVITY] Feb.28 -- Mar.06

Last week: * Launchpad #711819 / PR47719: ARM minipool ICE. Followed up on discussion with Bernd and Ramana. Later posted discussion results on gcc-patches, where Richard Earnshaw took it over with a final fix. * Coremark ARMv7/v6 regressions: mostly pinpointed the exact cases where RTL simplifica

[ACTIVITY] Mar.07 -- Mar.13

== Last week == * Working on Coremark ARMv6 regressions. Identified a major cause being RTL ifcvt failing on one of the crc routines, due to combine pass failing to optimize a particular sequence, causing the if-conversion estimates to give up on conditional executing (too many insns). The combin

[ACTIVITY] Mar.14 -- Mar.20

== Last week == * CoreMark ARMv6/v7 regressions: posted another combine patch upstream, which was quickly approved and committed. The XOR simplification one is now approved too, but needs a little more revising of comments before committing. * The above two patches now bring CoreMark under -march=

[ACTIVITY] Mar.21 -- Mar.27

== Last week == * PR46934: Thumb-1 ICE, small fix in the "casesi" jump-table expand code. Quickly approved and committed upstream. * Enhance XOR patch for gcc/simplify-rtx.c. Updated comments and committed upstream. * PR48250 / CS Issue #9845 / Launchpad #723185. Unaligned DImode reload under NEO

[ACTIVITY] Mar.28 -- Apr.03

== Last week == * PR48250 / CS Issue #9845 / Launchpad #723185. Unaligned DImode reload under NEON. Went back and forth with Richard Earnshaw on gcc-patches for most of the week. The issues should finally be clear, and I think it would be better to modify the significant parts of arm_legitimize_rel

[ACTIVITY] Apr.04 -- Apr.10

== Last week == * Mon/Tue (Apr.4--5): Tomb-sweeping Day, public holiday. * PR48250 / CS Issue #9845 / Launchpad #723185. Unaligned DImode reload under NEON. Worked on new patch, submitted to gcc-patches after testing on Friday. Awaiting review. == This week == * CoreMark ARMv6/v7 regressions: wor

CoreMark Status

Hi, I've just pushed a merge of the current upstream patches for resolving the CoreMark regressions. (https://code.launchpad.net/~cltang/gcc-linaro/coremark-part1) To give a quick benchmark of the current status, testing Linaro 4.5 before/after the merge of those two patches: Optimization options

[ACTIVITY] Apr.11 -- 17

== Last week == * CoreMark regressions: pushed a merge of my two upstream patches to Linaro 4.5, some current numbers are here: http://lists.linaro.org/pipermail/linaro-toolchain/2011-April/001087.html. * Continued working on another combine patch for improving CoreMark, hopefully ready to submit

[ACTIVITY] Apr.18 -- Apr.24

== Last week == * PR48250, rehaul arm_legitimize_reload_address(). Richard Sandiford caught a bug of mine where I overlooked the valid index range of NEON quad-word load/stores. Quickly whipped up a fix, soon approved and committed upstream. * LP #744754, ICE in NEON struct-mode auto-inc-dec MEMs.

Re: "BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0) " assert

I think I've seen this assert fail myself before, a long time ago... While this is probably a BFD bug of some sort, do you happen to have assembly code source files among the .o objects? Could you try adding ".eabi_attribute 27, 3" to the asm files and see if it links? On 2011/4/28 06:06 PM, Bar

Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko

On 2011/4/27 07:10 PM, Andrew Stubbs wrote: > On 27/04/11 10:57, Michael Hope wrote: >> Hi Andrew. I uploaded the wrong preprocessed source to the GCC >> bugzilla entry. It included the __attribute__((noinline)) workaround >> which hides the problem. > > OK, I've now reproduced the problem and r

[ACTIVITY] Apr.25 -- May.01

== Last week == * CoreMark ARMv6/v7 regression patch set for combine: exchanged some comments on upstream list with Jeff Law. Started some testing on powerpc64, hit some issues with native bootstrap that I don't think I completely overcome, but at least completed a 32-bit bootstrap successfully. Un

[ACTIVITY] May.02 -- May.08

== Last week == * Launchpad #748138: "ICE in redirect_jump, at jump.c:1443". Related to shrink-wrap, discussed a bit with Bernd off-list. Sent fix today (Mon.) to gnu-internal; will need to merge to Linaro. * CoreMark combine canonicalize compares patch set: bootstrapped and tested with clean resu

[ACTIVITY] May.09 -- May.15

== Last week == * At Linaro@UDS; I am still typing this in Budapest. Sparingly did some work between sessions. * PR42017, ARM LR register not being used. Discussed the patch with Richard Sandiford at LDS. Re-tested a bit and about to resend a revised patch according to his suggestion. * LP:748138

[ACTIVITY] May.16 -- May.22

== Last week == * Took Monday off, flew back to Taiwan on Tues., got home Wed. night. * LP:689887, ICE in get_arm_condition_code(). Finally have some new progress on this. Found my code was rejecting DImode comparisons, causing uses of __aeabi_lcmp, etc. in expanded RTL. While this still does not

[ACTIVITY] May.23 -- May.29

== Last week == * Investigated the CoreMark numbers posted by Michael Hope, mainly the oddities of a significant Linaro 4.6 regression versus FSF 4.6. Later verified to be a false alarm. * Pushed a merge of some of my upstream CoreMark patches to Linaro 4.6. * Did archeology for PR42017. Traced s

Re: How to fail an ARMv5T u-boot build when libgcc is ARMv7T2?

On 2011/11/10 06:04 PM, Loïc Minier wrote: > When building u-boot for an ARMv5T platform (versatileqemu_config), the > Ubuntu-packaged Linaro cross-toolchain isn't suitable because it > only offers an ARMv7T2 libgcc. But I'd like the build to fail when > that happens rather than silently genera

Re: Triage of #914703

On 2012/1/17 07:51 PM, Asa Sandahl wrote: > Hi Michael, > > So, I gave my best shot at: > > https://bugs.launchpad.net/gcc-linaro/+bug/914703 > > > Kind of similar to the one in your walk-through, but I couldn't actually > reproduce on the vers