]> git.ipfire.org Git - thirdparty/gcc.git/commit
dbr: Filter-out TARGET_FLAGS_REGNUM from end_of_function_needs.
authorHans-Peter Nilsson <hp@axis.com>
Mon, 10 Feb 2020 03:03:43 +0000 (04:03 +0100)
committerHans-Peter Nilsson <hp@axis.com>
Sat, 9 May 2020 00:51:48 +0000 (02:51 +0200)
commit2c2d405829ebb18de5357cc6319614035b420519
tree46d184c08d902f8f839b48fdda59ce10b476de13
parentce08aac1825bd367828532bd765355bf651df0c0
dbr: Filter-out TARGET_FLAGS_REGNUM from end_of_function_needs.

Compared to the cc0 version, I noticed a regression in
delay-slot-filling for CRIS for several functions in libgcc with
a similar layout, one being lshrdi3, where with cc0 all
delay-slots were filled, as exposed by the test-case in
gcc.target/cris/pr93372-1.c.

There's one slot that fails to be filled for the decc0rated CRIS
port.  A gdb session shows it is because of the automatic
inclusion of TARGET_FLAGS_REGNUM in "registers needed at the end
of the function" because there are insns in the epilogue that
clobber the condition-code register.  I'm not trying to tell a
clobber from a set, as parallels with set instead of clobber
seems likely to happen too, for targets with TARGET_FLAGS_REGNUM
set.

Other targets with delay-slots and one dedicated often-clobbered
condition-code-register should consider defining
TARGET_FLAGS_REGNUM.  I noticed it improved delay-slot-filling
also in other situations than this.

(Previously approved by Jeff Law.)

gcc:
* resource.c (init_resource_info): Filter-out TARGET_FLAGS_REGNUM
from end_of_function_needs.
gcc/ChangeLog
gcc/resource.c