In some cases the generated code contains (for arm target) a plus operator with positive constant which is followed by another plus operator with a negative constant and both operate on the same register (eg: "add rD, rB, #c0" and "sub rD, rD, #c1" ). This makes an opportunity for effective use of these operators if c0+c1 can be stored in the Immediate Operand filed. Specifically, in this case "add rD, rB, #c2" where c2 = c0 + c1 and c2 >= 0, or "sub rD, rB, #c2" where c2 = -(c0 + c1) and c2 < 0. This problem generally occurs when storing local variables on the stack. The same can be applied for all four combinations of plus and minus operators. In the example attached, in function foo there is a "sub r0,r0,#12" and "sub r0,r0,#4" which can be replaced by "sub r0,r0,#16". Release: GCC: (GNU) 3.3 20030324 (prerelease) Environment: BUILD & HOST: Linux 2.4.20 i686 unknown TARGET: arm-unknown-elf How-To-Repeat: arm-elf-gcc -S -g0 -Os plus-minus.c void func(char*); void foo() { char buf[1028]; func(buf); }
From: =?ISO-8859-2?Q?G=E1bor_L=F3ki?= <alga@rgai.hu> To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, alga@rgai.hu, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org Cc: Subject: Re: target/10242: ARM: peephole for effective use of plus and minus operators Date: Thu, 27 Mar 2003 15:45:45 +0100 Sorry, I submited this PR with a wrong Synopsis! The correct Synopsis: ARM: subsequent use of plus and minus operators could be improved May I ask somebody to fix it for me, please? Regards, Gábor Lóki
Hello, I can confirm that this behavior is still present on branch and mainline (20030508). Dara
see Dara's comment.
Still present with 4.4 mainline as on 20090312 revision. It looks like some sort of relic left behind with the calculations of the soft frame pointer. Maybe a peephole will help.
This is a case where early splitting (before register allocation) of a constant in a plus expression leads to poor code. We should try disabling the split of a plus when combined with the internal frame pointer.
Created attachment 17475 [details] Proposed fix -- will commit after trunk reopens
(In reply to comment #6) > Created an attachment (id=17475) [edit] > Proposed fix -- will commit after trunk reopens Ping, trunk is open now, no? I've been using this proposed fix in my gcc-4.3.4 based compiler for more than a month now without ill effects.
Subject: Bug 10242 Author: rearnsha Date: Wed Jun 3 23:31:12 2009 New Revision: 148156 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148156 Log: PR target/10242 * arm.md (arm_addsi3): Don't try to split an add with an eliminable register until after reload has completed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md
fixed