* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] unoptimal code generated
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
@ 2009-04-21 16:46 ` alexvod at google dot com
2009-04-21 16:47 ` alexvod at google dot com
` (17 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: alexvod at google dot com @ 2009-04-21 16:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from alexvod at google dot com 2009-04-21 16:45 -------
Created an attachment (id=17664)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17664&action=view)
gcc-rev123918.regr.c.139r.loop2_invariant
A dump of loop2_invariant phase with gcc rev123918
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] unoptimal code generated
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
2009-04-21 16:46 ` [Bug rtl-optimization/39837] " alexvod at google dot com
@ 2009-04-21 16:47 ` alexvod at google dot com
2009-04-21 16:49 ` pinskia at gcc dot gnu dot org
` (16 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: alexvod at google dot com @ 2009-04-21 16:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from alexvod at google dot com 2009-04-21 16:47 -------
Created an attachment (id=17665)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17665&action=view)
gcc-rev123919.regr.c.139r.loop2_invariant
A dump of loop2_invariant phase from gcc rev123919
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] unoptimal code generated
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
2009-04-21 16:46 ` [Bug rtl-optimization/39837] " alexvod at google dot com
2009-04-21 16:47 ` alexvod at google dot com
@ 2009-04-21 16:49 ` pinskia at gcc dot gnu dot org
2009-04-22 13:37 ` rguenth at gcc dot gnu dot org
` (15 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2009-04-21 16:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-21 16:49 -------
mov r5, r4
add r5, r5, #8
.L2:
ldr r2, [r4, #8]
mov r1, r5
Wait, r4+8 is the same as r5 here so loop invariant should have used it.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pinskia at gcc dot gnu dot
| |org
Target Milestone|--- |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] unoptimal code generated
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
` (2 preceding siblings ...)
2009-04-21 16:49 ` pinskia at gcc dot gnu dot org
@ 2009-04-22 13:37 ` rguenth at gcc dot gnu dot org
2009-04-23 16:40 ` alexvod at google dot com
` (14 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-04-22 13:37 UTC (permalink / raw)
To: gcc-bugs
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] unoptimal code generated
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
` (3 preceding siblings ...)
2009-04-22 13:37 ` rguenth at gcc dot gnu dot org
@ 2009-04-23 16:40 ` alexvod at google dot com
2009-05-20 14:17 ` ramana at gcc dot gnu dot org
` (13 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: alexvod at google dot com @ 2009-04-23 16:40 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from alexvod at google dot com 2009-04-23 16:39 -------
A more simple example of this issue:
void func(int*);
void test()
{
int a = 0;
while (1) {
func(&a);
if (a > 12) break;
}
}
GCC rev123918:
push {lr}
sub sp, sp, #12
mov r3, #0
str r3, [sp, #4]
.L2:
add r0, sp, #4
bl func
ldr r3, [sp, #4]
cmp r3, #12
ble .L2
add sp, sp, #12
@ sp needed for prologue
pop {pc}
GCC rev123919:
test:
push {r4, lr}
sub sp, sp, #8
mov r3, #0
add r4, sp, #4
str r3, [sp, #4]
.L2:
mov r0, r4
bl func
ldr r3, [sp, #4]
cmp r3, #12
ble .L2
add sp, sp, #8
@ sp needed for prologue
pop {r4, pc}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] unoptimal code generated
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
` (4 preceding siblings ...)
2009-04-23 16:40 ` alexvod at google dot com
@ 2009-05-20 14:17 ` ramana at gcc dot gnu dot org
2009-08-04 12:49 ` [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM rguenth at gcc dot gnu dot org
` (12 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: ramana at gcc dot gnu dot org @ 2009-05-20 14:17 UTC (permalink / raw)
To: gcc-bugs
--
ramana at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-05-20 14:17:04
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
` (5 preceding siblings ...)
2009-05-20 14:17 ` ramana at gcc dot gnu dot org
@ 2009-08-04 12:49 ` rguenth at gcc dot gnu dot org
2010-01-02 0:42 ` steven at gcc dot gnu dot org
` (11 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-08-04 12:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from rguenth at gcc dot gnu dot org 2009-08-04 12:30 -------
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.3.4 |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
` (6 preceding siblings ...)
2009-08-04 12:49 ` [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM rguenth at gcc dot gnu dot org
@ 2010-01-02 0:42 ` steven at gcc dot gnu dot org
2010-01-29 23:11 ` steven at gcc dot gnu dot org
` (10 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: steven at gcc dot gnu dot org @ 2010-01-02 0:42 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from steven at gcc dot gnu dot org 2010-01-02 00:42 -------
Working with "gcc (GCC) 4.5.0 20090808 (experimental) [trunk revision 150579]",
I looked at what loop-invariant.c did to the test case.
This is the "t.c.154r.loop2" RTL dump (obtained with -fdump-rtl-all-slim):
;; Function test (test)
3 NOTE_INSN_BASIC_BLOCK
6 r135:SI=unspec[const(unspec[const(unspec[0x0] 21+0x4)] 24)] 3
7 r135:SI=unspec[r135:SI,0x4,0x0] 4
8 use r135:SI
2 NOTE_INSN_FUNCTION_BEG
L20:
5 NOTE_INSN_BASIC_BLOCK
9 r137:SI=unspec[`g'] 3
10 r136:SI=[r135:SI+r137:SI]
REG_DEAD: r137:SI
REG_EQUAL: `g'
11 r133:SI=[r136:SI+0x8]
REG_EQUAL: [const(`g'+0x8)] ! Pay close attention here...
14 r138:SI=r136:SI+0x8
REG_DEAD: r136:SI
REG_EQUAL: const(`g'+0x8) ! ...and here
15 r0:SI=r133:SI
16 r1:SI=r138:SI
REG_DEAD: r138:SI
REG_EQUAL: const(`g'+0x8)
17 r2:SI=r133:SI
REG_DEAD: r133:SI
18 r0:SI=call [`func'] argc:0x0
REG_DEAD: r2:SI
REG_DEAD: r1:SI
19 r134:SI=r0:SI
REG_DEAD: r0:SI
21 pc={(r134:SI!=0x0)?L20:pc}
REG_DEAD: r134:SI
REG_BR_PROB: 0x238c
24 NOTE_INSN_BASIC_BLOCK
The code has a load from the address "const(`g'+0x8)" and a load of the
constant itself to a register:
11 r133:SI=[r136:SI+0x8]
14 r138:SI=r136:SI+0x8
loop-invariant.c correctly notices the constant in insn 14 can be moved and it
moves the set to reg 138 from basic block 3 to basic block 2 (from the
"t.c.156r.loop2_invariant" dump, all "deferring rescan insn*" lines removed):
Set in insn 9 is invariant (0), cost 4, depends on
Set in insn 10 is invariant (1), cost 4, depends on 0
Set in insn 14 is invariant (2), cost 4, depends on 1
Set in insn 16 is invariant (3), cost 0, depends on 2
Decided to move invariant 2
Decided to move invariant 1
Decided to move invariant 0
changing bb of uid 9
from 3 to 2
changing bb of uid 10
from 3 to 2
changing bb of uid 14
from 3 to 2
The resulting RTL dump is this:
3 NOTE_INSN_BASIC_BLOCK
6 r135:SI=unspec[const(unspec[const(unspec[0x0] 21+0x4)] 24)] 3
7 r135:SI=unspec[r135:SI,0x4,0x0] 4
8 use r135:SI
2 NOTE_INSN_FUNCTION_BEG
9 r140:SI=unspec[`g'] 3
10 r141:SI=[r135:SI+r140:SI]
REG_DEAD: r137:SI
REG_EQUAL: `g'
14 r142:SI=r141:SI+0x8
REG_DEAD: r136:SI
REG_EQUAL: const(`g'+0x8)
L20:
5 NOTE_INSN_BASIC_BLOCK
46 r137:SI=r140:SI
47 r136:SI=r141:SI
11 r133:SI=[r141:SI+0x8] ! Aha! Why not r133=[r142] here?
REG_EQUAL: [const(`g'+0x8)]
48 r138:SI=r142:SI
15 r0:SI=r133:SI
16 r1:SI=r142:SI
REG_DEAD: r138:SI
REG_EQUAL: const(`g'+0x8)
17 r2:SI=r133:SI
REG_DEAD: r133:SI
18 r0:SI=call [`func'] argc:0x0
REG_DEAD: r2:SI
REG_DEAD: r1:SI
19 r134:SI=r0:SI
REG_DEAD: r0:SI
21 pc={(r134:SI!=0x0)?L45:pc}
REG_DEAD: r134:SI
REG_BR_PROB: 0x238c
L45:
44 NOTE_INSN_BASIC_BLOCK
24 NOTE_INSN_BASIC_BLOCK
After loop-invariant.c, reg 142 is set to "const(`g'+0x8)" in basic block 2,
before the loop:
14 r142:SI=r141:SI+0x8
But inside the loop, r142 is only used in insn 48 to set reg 138 (it was set in
insn 14 before loop-invariant.c). The fact that r142="const(`g'+0x8)" is not
used in insn 11:
11 r133:SI=[r141:SI+0x8]
48 r138:SI=r142:SI
Somehow, loop-invariant has failed to notice or exploit the equivalence.
--
steven at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2009-06-22 16:28:19 |2010-01-02 00:42:32
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
` (7 preceding siblings ...)
2010-01-02 0:42 ` steven at gcc dot gnu dot org
@ 2010-01-29 23:11 ` steven at gcc dot gnu dot org
2010-01-30 9:47 ` rakdver at kam dot mff dot cuni dot cz
` (9 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: steven at gcc dot gnu dot org @ 2010-01-29 23:11 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from steven at gcc dot gnu dot org 2010-01-29 23:11 -------
Created an attachment (id=19755)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19755&action=view)
Hack to look for invariants inside MEMs
Re. comment #4:
The following code would also be correct, right?
test:
push {r4, lr}
sub sp, sp, #8
mov r3, #0
add r4, sp, #4
str r3, [sp, #4]
.L2:
mov r0, r4
bl func
ldr r3, [r4]
cmp r3, #12
ble .L2
add sp, sp, #8
@ sp needed for prologue
pop {r4, pc}
.size test, .-test
.ident "GCC: (GNU) 4.5.0 20100129 (experimental) [trunk revision
156352]"
I have a really bad hack that makes loop-invariant look at addresses inside
MEMs (attached).
(Looking at Zdenek:) Would something like this in a more polished and actually
verified&tested form be a good idea?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
` (8 preceding siblings ...)
2010-01-29 23:11 ` steven at gcc dot gnu dot org
@ 2010-01-30 9:47 ` rakdver at kam dot mff dot cuni dot cz
2010-03-02 19:59 ` pinskia at gcc dot gnu dot org
` (8 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: rakdver at kam dot mff dot cuni dot cz @ 2010-01-30 9:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from rakdver at kam dot mff dot cuni dot cz 2010-01-30 09:47 -------
Subject: Re: [4.3/4.4/4.5 regression] extra
spills due to RTL LICM
> (Looking at Zdenek:) Would something like this in a more polished and actually
> verified&tested form be a good idea?
I think this could cause us to move the invariant addresses out of the loop
unnecessarily. Note that moving "const(`g'+0x8)" out of the loop is only a
good idea because it is used elsewhere -- if it were only used as the address,
moving it out adds an unnecessary assignment. This could be handled by the
patch by ignoring the address invariants in find_invariants_to_move.
Otherwise, the idea looks fine to me (assuming that there are reasons why this
is not done by fwprop),
Zdenek
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
` (9 preceding siblings ...)
2010-01-30 9:47 ` rakdver at kam dot mff dot cuni dot cz
@ 2010-03-02 19:59 ` pinskia at gcc dot gnu dot org
2010-03-02 20:10 ` pinskia at gcc dot gnu dot org
` (7 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2010-03-02 19:59 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from pinskia at gcc dot gnu dot org 2010-03-02 19:59 -------
I think this is the same issue as PR 36758.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |36758
GCC build triplet|x86_64-unknown-linux-gnu |
GCC host triplet|x86_64-unknown-linux-gnu |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
` (10 preceding siblings ...)
2010-03-02 19:59 ` pinskia at gcc dot gnu dot org
@ 2010-03-02 20:10 ` pinskia at gcc dot gnu dot org
2010-07-10 21:07 ` sandra at codesourcery dot com
` (6 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2010-03-02 20:10 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from pinskia at gcc dot gnu dot org 2010-03-02 20:10 -------
Actually looking at comment #4 shows that is an exact duplicate of PR 36758 so
closing as a dup.
*** This bug has been marked as a duplicate of 36758 ***
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
` (11 preceding siblings ...)
2010-03-02 20:10 ` pinskia at gcc dot gnu dot org
@ 2010-07-10 21:07 ` sandra at codesourcery dot com
2010-07-11 7:51 ` bonzini at gnu dot org
` (5 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: sandra at codesourcery dot com @ 2010-07-10 21:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from sandra at codesourcery dot com 2010-07-10 21:07 -------
I just checked to see if this is still a problem. As of r162042, the example
in comment #1 produces the same (bad) output as GCC 4.4.1. However, the example
in comment #4 looks fixed to me, with this output:
test:
push {r0, r1, r2, lr}
mov r3, #0
str r3, [sp, #4]
.L2:
add r0, sp, #4
bl func
ldr r3, [sp, #4]
cmp r3, #12
ble .L2
@ sp needed for prologue
pop {r0, r1, r2, pc}
As it was the latter test case that caused this to be marked as a duplicate of
PR 36758, maybe the original test case is tripping over a different problem and
needs to be re-examined?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
` (12 preceding siblings ...)
2010-07-10 21:07 ` sandra at codesourcery dot com
@ 2010-07-11 7:51 ` bonzini at gnu dot org
2010-07-11 11:40 ` steven at gcc dot gnu dot org
` (4 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: bonzini at gnu dot org @ 2010-07-11 7:51 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from bonzini at gnu dot org 2010-07-11 07:51 -------
I agree.
--
bonzini at gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|DUPLICATE |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
` (13 preceding siblings ...)
2010-07-11 7:51 ` bonzini at gnu dot org
@ 2010-07-11 11:40 ` steven at gcc dot gnu dot org
2010-07-11 17:47 ` sandra at codesourcery dot com
` (3 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: steven at gcc dot gnu dot org @ 2010-07-11 11:40 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from steven at gcc dot gnu dot org 2010-07-11 11:40 -------
Does the prototype fix of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758#c21
help?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
` (14 preceding siblings ...)
2010-07-11 11:40 ` steven at gcc dot gnu dot org
@ 2010-07-11 17:47 ` sandra at codesourcery dot com
2010-07-11 22:48 ` steven at gcc dot gnu dot org
` (2 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: sandra at codesourcery dot com @ 2010-07-11 17:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from sandra at codesourcery dot com 2010-07-11 17:47 -------
Yes, it looks like the prototype fix for PR 36758 fixes the test case at the
top of this issue. The patch needs a little updating, though, and I can't say
I grok the changes to the surrounding code sufficiently to be sure I've gotten
it right.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
` (15 preceding siblings ...)
2010-07-11 17:47 ` sandra at codesourcery dot com
@ 2010-07-11 22:48 ` steven at gcc dot gnu dot org
2010-07-11 22:55 ` steven at gcc dot gnu dot org
2010-07-13 17:13 ` sandra at codesourcery dot com
18 siblings, 0 replies; 21+ messages in thread
From: steven at gcc dot gnu dot org @ 2010-07-11 22:48 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from steven at gcc dot gnu dot org 2010-07-11 22:48 -------
Well, it's probably worth trying a little harder to grok them, then. Zdenek has
already said that the fix looks OK in principle, but I am not interested at all
in working on this patch anymore (especially not when others with an interest
in the patch get paid for caring :-).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
` (16 preceding siblings ...)
2010-07-11 22:48 ` steven at gcc dot gnu dot org
@ 2010-07-11 22:55 ` steven at gcc dot gnu dot org
2010-07-13 17:13 ` sandra at codesourcery dot com
18 siblings, 0 replies; 21+ messages in thread
From: steven at gcc dot gnu dot org @ 2010-07-11 22:55 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from steven at gcc dot gnu dot org 2010-07-11 22:55 -------
Brief explanation about what the patch does:
* have a pointer to the location of the invariant within an rtx. The existing
code assumes a complete RHS is invariant, but with the patch GCC can move
invariants out of the RHS of a SET even if the whole RHS itself is not
invariant.
* Do not bail out in find_invariant_insn if the complete RHS is not invariant.
Instead see if there is an address (i.e. XEXP (MEM, 0)) that is invariant.
* Update invariant motion code to handle partially invariant RHSs
One TODO for the patch (IIRC) is to only move an invariant address if it would
otherwise be moved anyway. That is, only move the invariant address if there is
a dependent invariant that would cause the address to be hoisted anyway. This
is to avoid excessive LICM.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] extra spills due to RTL LICM
2009-04-21 16:44 [Bug rtl-optimization/39837] New: [4.3/4.4/4.5 regression] unoptimal code generated alexvod at google dot com
` (17 preceding siblings ...)
2010-07-11 22:55 ` steven at gcc dot gnu dot org
@ 2010-07-13 17:13 ` sandra at codesourcery dot com
18 siblings, 0 replies; 21+ messages in thread
From: sandra at codesourcery dot com @ 2010-07-13 17:13 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from sandra at codesourcery dot com 2010-07-13 17:13 -------
As a point of clarification, I am not getting paid to care about this issue
either. :-) At this time I have no plans to continue working on it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
^ permalink raw reply [flat|nested] 21+ messages in thread