public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/41004] New: missed merge of basic blocks
@ 2009-08-08 0:10 carrot at google dot com
2009-08-08 0:10 ` [Bug target/41004] " carrot at google dot com
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: carrot at google dot com @ 2009-08-08 0:10 UTC (permalink / raw)
To: gcc-bugs
Compile the attached source code with options -Os -march=armv5te -mthumb
Gcc generates following code snippet:
...
cmp r0, r2
bne .L5
b .L15 <--- A
.L9:
ldr r3, [r1]
cmp r3, #0
beq .L7
str r0, [r1, #8]
b .L8
.L7:
str r3, [r1, #8]
.L8:
ldr r1, [r1, #4]
b .L12 <---- C
.L15:
mov r0, #1 <--- B
.L12:
cmp r1, r2 <---- D
bne .L9
...
inst A jump to B then fall through to D
inst C jump to D
there is no other instructions jump to instruction B, so we can put inst B just
before A, then A jump to D, and C can be removed.
There are two possible functions can potentially do this optimization. They are
merge_blocks_move and try_forward_edges.
Function try_forward_edges can only redirect a series of forwarder blocks. It
can't move the target blocks before the forwarder blocks.
In function merge_blocks_move only when both block b and c aren't forwarder
blocks then can they be merged. In this case block A is a forwarder block, so
they are not merged.
--
Summary: missed merge of basic blocks
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/41004] missed merge of basic blocks
2009-08-08 0:10 [Bug target/41004] New: missed merge of basic blocks carrot at google dot com
@ 2009-08-08 0:10 ` carrot at google dot com
2009-08-08 9:07 ` steven at gcc dot gnu dot org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: carrot at google dot com @ 2009-08-08 0:10 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from carrot at google dot com 2009-08-08 00:10 -------
Created an attachment (id=18326)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18326&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/41004] missed merge of basic blocks
2009-08-08 0:10 [Bug target/41004] New: missed merge of basic blocks carrot at google dot com
2009-08-08 0:10 ` [Bug target/41004] " carrot at google dot com
@ 2009-08-08 9:07 ` steven at gcc dot gnu dot org
2009-08-08 10:07 ` [Bug middle-end/41004] " steven at gcc dot gnu dot org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: steven at gcc dot gnu dot org @ 2009-08-08 9:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from steven at gcc dot gnu dot org 2009-08-08 09:07 -------
Why does the basic block reordering pass also not handle this?
--
steven 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-08-08 09:07:04
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug middle-end/41004] missed merge of basic blocks
2009-08-08 0:10 [Bug target/41004] New: missed merge of basic blocks carrot at google dot com
2009-08-08 0:10 ` [Bug target/41004] " carrot at google dot com
2009-08-08 9:07 ` steven at gcc dot gnu dot org
@ 2009-08-08 10:07 ` steven at gcc dot gnu dot org
2009-08-08 10:36 ` rguenth at gcc dot gnu dot org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: steven at gcc dot gnu dot org @ 2009-08-08 10:07 UTC (permalink / raw)
To: gcc-bugs
--
steven at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2009-08-08 09:07:04 |2009-08-08 10:06:54
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug middle-end/41004] missed merge of basic blocks
2009-08-08 0:10 [Bug target/41004] New: missed merge of basic blocks carrot at google dot com
` (2 preceding siblings ...)
2009-08-08 10:07 ` [Bug middle-end/41004] " steven at gcc dot gnu dot org
@ 2009-08-08 10:36 ` rguenth at gcc dot gnu dot org
2009-08-19 21:55 ` carrot at google dot com
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-08-08 10:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-08 10:36 -------
I would suggest to closely look at SSA expansion as well. There is I think
still the regression from pre-SSA expand that it doesn't expand PHI nodes
optimally at -Os (pre-SSA expand split common PHI args into extra blocks to
minimize copy instructions which is something that can be done as a tree
level transform). Like
BB5:
# a_1 = PHI <a_2(2), a_2(3), b_3(4)>
to
BB6:
# tmp_4 = PHI <a_2(2), a_2(3)>
BB5:
# a_1 = PHI <tmp_4(6), b_3(4)>
which we usually don't want and in fact undo during mergephi. But it needs
one less copy if a_2 and tmp_4 can be coalesced together.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug middle-end/41004] missed merge of basic blocks
2009-08-08 0:10 [Bug target/41004] New: missed merge of basic blocks carrot at google dot com
` (3 preceding siblings ...)
2009-08-08 10:36 ` rguenth at gcc dot gnu dot org
@ 2009-08-19 21:55 ` carrot at google dot com
2009-08-19 23:07 ` rth at gcc dot gnu dot org
2010-01-11 9:36 ` steven at gcc dot gnu dot org
6 siblings, 0 replies; 8+ messages in thread
From: carrot at google dot com @ 2009-08-19 21:55 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from carrot at google dot com 2009-08-19 21:55 -------
(In reply to comment #2)
> Why does the basic block reordering pass also not handle this?
>
Basic block reordering is disabled with options -Os.
The basic block reordering algorithm is for performance only, it usually
increases code size. So it won't be called when do optimization for size. But
for this specific case, the extra branch can be removed when I compile it with
-O2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug middle-end/41004] missed merge of basic blocks
2009-08-08 0:10 [Bug target/41004] New: missed merge of basic blocks carrot at google dot com
` (4 preceding siblings ...)
2009-08-19 21:55 ` carrot at google dot com
@ 2009-08-19 23:07 ` rth at gcc dot gnu dot org
2010-01-11 9:36 ` steven at gcc dot gnu dot org
6 siblings, 0 replies; 8+ messages in thread
From: rth at gcc dot gnu dot org @ 2009-08-19 23:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from rth at gcc dot gnu dot org 2009-08-19 23:06 -------
Basic block reordering *should* be altered to work with -Os.
It's definitely required to clean up silly jump sequences that
exception handling creates.
There's no reason, in principal, that the ordering algorithm
can't be adjusted to minimize the number of branches, or the
total size of all of the branch instructions (though that could
require some clever changes to the shorten_branches code).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug middle-end/41004] missed merge of basic blocks
2009-08-08 0:10 [Bug target/41004] New: missed merge of basic blocks carrot at google dot com
` (5 preceding siblings ...)
2009-08-19 23:07 ` rth at gcc dot gnu dot org
@ 2010-01-11 9:36 ` steven at gcc dot gnu dot org
6 siblings, 0 replies; 8+ messages in thread
From: steven at gcc dot gnu dot org @ 2010-01-11 9:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from steven at gcc dot gnu dot org 2010-01-11 09:35 -------
Re. comment #5 -- rth, any suggestions what an algorithm would look like to
"minimize the number of branches, or the total size of all of the branch
instructions"? And what do you mean with "some clever changes to the
shorten_branches code"? Did you mean the calculation of insn sizes, or
avoiding padding, or something else completely? Hope you can help a bit...
--
steven at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-01-11 9:36 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-08 0:10 [Bug target/41004] New: missed merge of basic blocks carrot at google dot com
2009-08-08 0:10 ` [Bug target/41004] " carrot at google dot com
2009-08-08 9:07 ` steven at gcc dot gnu dot org
2009-08-08 10:07 ` [Bug middle-end/41004] " steven at gcc dot gnu dot org
2009-08-08 10:36 ` rguenth at gcc dot gnu dot org
2009-08-19 21:55 ` carrot at google dot com
2009-08-19 23:07 ` rth at gcc dot gnu dot org
2010-01-11 9:36 ` steven at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).