This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Is CSE getting more conservative on 2.95.3.test3?
- To: gcc-bugs at gcc dot gnu dot org
- Subject: Is CSE getting more conservative on 2.95.3.test3?
- From: Kazu Hirata <kazu at hxi dot com>
Hi,
When I compile gcc.c-torture/execute/20000313-1.c on h8300-hms with
both 2.95.2 and 2.95.3 and compare the results, I get an extra basic
block as follows.
h8300-hms-gcc -mh -mint32 -O3
_main:
push.l er6
mov.l er7,er6
subs #4,sp
sub.l er2,er2
mov.l er2,@(-4,er6)
mov.l er2,er2
beq .L9
jsr @_abort
.L9:
+ sub.l er2,er2
+ subs #1,er2
+ bne .L10
+ jsr @_abort
+.L10:
sub.l er0,er0
adds #4,sp
pop.l er6
rts
Looking at the basic block starting from .L9, it is obvious that er2
contains -1. Since the zero flag is cleared, bne (branch if not
equal) should always jump to .L10. Comparing both results, 2.95.2
successfully gets rid of the basic block during CSE2, but 2.95.3
leaves it there.
p.s.
By the way, the above is the only regression between 2.95.2 and
2.95.3.test3 on h8300-hms. The failure itself is caused by a bug in
the machine description; cc0 in one of the move patterns is
incorrectly specified. We actually need a test instruction right
after the loading of -1. Nonetheless, the basic block above is
mysterious.
h8300-hms-gcc -mh -mint32
FAIL: gcc.c-torture/execute/20000313-1.c execution, -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/20000313-1.c execution, -O3 -g
Thanks,
Kazu Hirata