This pass sinks COPY instructions into a successor close to their useblock, if the COPY is not
unuused in the current block. In and the CodeGen phase, COPY instructions areOPY is live-in to a single successor
added in some passes (e.g(i.e., ISel and PhiElimination), which are not handleddoesn't require the COPY to be duplicated). This avoids executing the
in MachineSink pass. For example, in AArch64, ISel adds Copy instructions tothe copy on paths where their results aren't needed. This also exposes
move function parameters (PhyReg) to virtual registers in the entry block.
Before RA, MachineSink cannot sink such Copy instructions because SrcReg isadditional opportunites for dead copy elimination and shrink wrapping.
These copies were either not handled by or are inserted after the MachineSink
an allocatable PhyReg.pass. As an example of the former case, By sinking such COPY instructions to successors closethe MachineSink pass cannot sink
to its actual use,COPY instructions with allocatable source registers; we can avoid executing instructions in case the result isfor AArch64 these type
not used. Also, it will open up more opportunities for other optimizationsof copy instructions are frequently used to move function parameters (PhyReg)
(e.g., dead copy elimination in MachineCopyPropagation and shrink-wrapping).
For example, forinto virtual registers in the entry block..
For the machine IR below, this pass will sink %w19 in the entry into its
into its successor (%bb.1) because %w19 is only live-in in %bb.1.
%wzr = SUBSWri %w1, 1
%w19 = COPY %w0
Bcc 11, %bb.2
Live Ins: %w19
%w0 = ADDWrr %w0, %w19
%w0 = COPY %wzr
As we sink %w19 (CSR in AArch64) into %bb.1, the shrink-wrapping pass will be
able to see %bb.0 as a candidate.
With this change I observed 12% more shrink-wrapping candidate and 13% more dead copies deleted in spec2000/2006/2017 on AArch64.