https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64156
--- Comment #3 from Wilco <wdijkstr at arm dot com> ---
(In reply to Michael Meissner from comment #2)
> Note, the fix proposed in PR64151 DOES NOT work on the PowerPC, so it may be
> a dup in terms of what change broke the build, but the potential fix needs
> more analysis.
The basic issue is similar, we end up with negative mem_cost for some constant
loads due to LEGITIMATE_PIC_OPERAND_P being true for (symbol_ref:SI
("*.LANCHOR0") [flags 0x182]) in:
(insn 41 40 42 9 (set (reg/f:SI 173)
(mem/u/c:SI (unspec:SI [
(symbol_ref/u:SI ("*.LC1") [flags 0x2])
(reg:SI 30 30)
] UNSPEC_TOCREL) [3 S4 A8])) powisf2.c:15 403
{*movsi_internal1}
(expr_list:REG_EQUIV (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
(nil)))
(insn 42 41 43 9 (set (reg:SF 172)
(mem/u/c:SF (reg/f:SI 173) [1 S4 A32])) powisf2.c:15 409
{movsf_hardfloat}
(expr_list:REG_DEAD (reg/f:SI 173)
(expr_list:REG_EQUIV (const_double:SF 1.0e+0 [0x0.8p+1])
(nil))))
The interesting thing here is that the 2nd load is already processed in the
same way (as it is a legitimate constant. The original costs are 264 for r172
and 0 for r273. However if the first load has its mem_cost changed too, then
BOTH r172 and r173 end up with a negative cost (-198 and -66). Also both loads
are single-use and already right next to their use, so in principle don't need
this mem_cost adjustment as they cannot be spilled.
When the first load is rematerialized in reload it seems to be copied
incorrectly (possibly because the REG_EQUIV is lost at some point), resulting
in an odd LC2 symbol:
(insn 80 42 81 9 (set (reg:SI 9 9)
(mem/u/c:SI (unspec:SI [
(symbol_ref/u:SI ("*.LC2") [flags 0x2])
(reg:SI 30 30)
] UNSPEC_TOCREL) [3 S4 A8])) powisf2.c:15 403
{*movsi_internal1}
(nil))
It seems this issue could happen without the mem_move cost adjustment, say for
example if the first load had been CSEd and used for several constants across a
large function. In that case it might be spilled due to register pressure, so
if reload cannot rematerialize it correctly, it should keep the original load
instruction and force a standard spill/reload instead.
Anyway it looks like this patch has triggered some complex allocation issues,
so it seems best to revert it. I'll get someone to do that tomorrow unless
someone else has already done it by then.
