This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Is CSE getting more conservative on 2.95.3.test3?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]