On 3/27/23 11:01, Richard Sandiford wrote:
Jin Ma via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
Unrecog insns (such as CLOBBER, USE) does not represent real instructions,
but in the
process of pipeline optimization, they will wait for transmission in ready list
like
other insns, without considering resource conflicts and cycles. This results in
a
multi-issue CPU architecture that can be issued at any time if other regular
insns
have resource conflicts or cannot be launched for other reasons. As a result,
its
position is advanced in the generated insns sequence, which will affect register
allocation and often lead to more redundant mov instructions.
Is it the clobber rather than the use case that is causing problems?
I would expect that scheduling a use ASAP would be better for register
pressure, since it might close off the associated live range and so
reduce the number of conflicts.
Agreed. Issuing USES as soon as possible seems advisable from a
register pressure standpoint.
A clobber can close off a range as well, but I suspect that is the
exception rather than the norm.
I.e. is the problem that, when a live range starts with a clobber,
the current code will tend to move the clobber up and so extend
the associated live range? If so, that sounds like something we
should address more directly, for two reasons:
Agreed as well. I would expect the normal case for clobbers is that
deferring them as late as possible is best as I would expect they
typically open a live range.
(1) We should try to prevent clobbers that start a live range from being
moved up even if first_cycle_insn_p.
Yes.
(2) Clobbers can also be used to close off a live range, which is useful
if a pseudo is only written to in parts. The current behaviour is
probably better for those clobbers.
I thought these sequences started with a clobber, then the component
sets. In which case the clobber isn't closing a live range, but opening
one and deferring it is advisable.
jeff
