Hi,
When considering a candidate for rematerialization, LRA verifies if
the candidate clobbers a live register before going forward with the
rematerialization (see code starting with comment "Check clobbers do
not kill something living."). To do this check, the set of live
registers at any given instruction needs to be maintained. This is
done by initializing the set of live registers when starting the
forward scan of instruction in a basic block and updating the set by
looking at REG_DEAD notes and destination register at the end of an
iteration of the scan loop.
However the initialization suffers from 2 issues:
1) it is done from the live out set rather than live in (uses
df_get_live_out (bb))
2) it ignores pseudo registers that have already been allocated a hard
register (uses REG_SET_TO_HARD_REG_SET that only looks at hard
register and does not look at reg_renumber for pseudo registers)
This patch changes the code to use df_get_live_in (bb) to initialize
the live_hard_regs variable using a loop to check reg_renumber for
pseudo registers. Please let me know if there is a macro to do that, I
failed to find one.
ChangeLog entries are as follow:
gcc/testsuite/ChangeLog:
2016-12-01 Thomas Preud'homme <thomas.preudhomme@arm.com>
PR rtl-optimization/78617
* gcc.c-torture/execute/pr78617.c: New test.
gcc/ChangeLog:
2016-12-01 Thomas Preud'homme <thomas.preudhomme@arm.com>
PR rtl-optimization/78617
* lra-remat.c (do_remat): Initialize live_hard_regs from live in
registers, also setting hard registers mapped to pseudo
registers.
Note however that as explained in the problem report, the testcase
does not trigger the bug on GCC 7 due to better optimization before
LRA rematerialization is reached.
Testing: testsuite shows no regression when run using:
+ an arm-none-eabi GCC cross-compiler targeting Cortex-M0 and Cortex-M3
+ a bootstrapped arm-linux-gnueabihf GCC native compiler
+ a bootstrapped x86_64-linux-gnu GCC native compiler
Is this ok for stage3?