[PATCH] D20531: MachineCopyPropagation: remove some more copys when they are not needed

[Matthias Braun via llvm-commits]

MatzeB added a comment.

I haven't looked at the change yet, but this is how I see MCPs role:

> Why is this pass so simple? It is not trusting live-in lists, and not recomputing liveness -- is this something "todo", or? My first thought was that liveness could be checked with a reaching phys defs algorithm (see http://reviews.llvm.org/D17257), and basically the pass could be doing a bit more work then. After working with this benchmark, it became clear that even a single COPY could make a noticable difference (SPEC/bzip2).


The MachineCopyPropagation started as an ad-hoc fix for some cases that the register allocator did not handle. I assume we simply never tried to use something more sophisticated. While we probably would have no problem with a more sophisticated MCP pass the question we really should answer first is why all the other mechanisms failed to eliminate the copy:
There is the aggressive and extensive RegisterCoalescer pass, the PeepholeOptimizer removes cross register bank copies and the allocator has hinting mechanism for the few cases we cannot remove in the RegisterCoalescer. So before extending the MCP pass we should try to understand why you ended up with that copy. My first guess would be that the RegisterCoalescer should remove the COPY from your example (though it's hard to judge from the limited context).


http://reviews.llvm.org/D20531