[PATCH] D40755: [WIP][shrink-wrap]Sink COPYs to CSR from entry to successors

[Jun Bum Lim via Phabricator via llvm-commits]

junbuml added a comment.



> What if we can sink through but in the end it's not useful for shrink-wrapping (something else is blocking) ? We should be able to revert, or anticipate this in the first place.

- This is certainly possible, but I'm not sure about the negative cases by sinking such Copys in post-RA.
- By moving Copys into a successor, we can avoid executing instructions in case the result is not used.
- If there is any undesirable impact by sinking with no use of shrink-wrappping, I may want to check if doing so can help shrink wrapping first instead of reverting.

> I liked the idea that shrink-wrapping is only analyzing and not modifying the code until PEI, is there any other pass where this would fit better?

- Actaully, I'm also not fully happy with doing this in shrink-wrapping pass. That's why I said this is WIP.
- It should be done between RA and shrink-wrapping, but I cannot see any good existing pass where this can be placed.

> Would a post-RA MachineSink pass make sense here ? (in a way that's what shrink-wrapping really is)

- I don't sink this is a bad option if there is any other case which is not handled in pre-RA MachineSink pass.

> I wonder how much extra work the register allocator would do if we sink (during pre-RA MachineSink) the %vreg = COPY %arg into the successor and add %arg as a live-in.

- It sounds like another option. However, for me, based on the comment in FindSuccToSinkTo() in MachineSink, it seems require pretty fundamental changes in RA. Quentin may have opinion about this.


https://reviews.llvm.org/D40755