[Bug target/70989] New: [SH] Further improve utilization of zero-displacement conditional branches
olegendo at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Sat May 7 02:55:00 GMT 2016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70989
Bug ID: 70989
Summary: [SH] Further improve utilization of zero-displacement
conditional branches
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Created attachment 38432
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38432&action=edit
Simplify SH abs patterns
The change in r235993 disables the delay branch for conditional branches during
the DBR pass, if the branch skips a single instruction. This improves the
utilization of zero-displacement cbranches.
There are still some cases where other basic block optimizations would reorder
blocks in a way which makes zero-displacement cbranches impossible to use.
For example, when the abs patterns are simplified we get the following code in
CSiBE (cg_compiler_opensrc/compile.c).
Before:
.L872:
cmp/pz r6
mov.l .L1024,r13
mov r6,r1
bt 0f
neg r6,r1
0:
mov.l r1,@(32,r15)
After:
.L872:
cmp/pz r6
bt/s .L1004
mov.l r6,@(32,r15)
bra .L1010
neg r6,r1
.L1004:
mov.l @(32,r15),r2
....
< many blocks here >
...
.L1010:
bra .L1004
mov.l r1,@(32,r15)
.align 1
.L1015:
With -fno-reorder-blocks it's a bit better (from the branching point of view):
L818:
cmp/pz r6
bt/s .L950
mov.l r6,@(32,r15)
neg r6,r1
mov.l r1,@(32,r15)
.L950:
mov.l @(32,r15),r2
And with -fno-reorder-blocks -fno-delayed-branch it's clear that it's almost
impossible to recover the zero-displacement branch at this stage anymore:
.L794:
cmp/pz r6
mov.l r6,@(32,r15)
bt .L926
neg r6,r1
mov.l r1,@(32,r15)
.L926:
mov.l @(32,r15),r2
Disallowing transformation of 1-insn cbranches in the bb-reorder pass might
lead to some improvements, but I guess that these 1-insn branches have to be
"pinned" much earlier during compilation to get better results.
More information about the Gcc-bugs
mailing list