A lot of these copies are useless (copies b/w VRegs having the same regclass) and should be cleaned up so that later passes don't have to all check to walk through the source of copies.
Diff Detail
Event Timeline
Sounds like a good thing to do.
One comment inline.
lib/CodeGen/GlobalISel/InstructionSelect.cpp | ||
---|---|---|
194 | Instead of having another pass through the IR for this, could we do it while we do the ISel loop? Meaning, if the register banks match, push the RC to the def and let constraint operand create a new copy if need be. |
lib/CodeGen/GlobalISel/InstructionSelect.cpp | ||
---|---|---|
162 | Why are you calling this MBI? It's a "MachineBasicBlock &", so it should really just be called MBB. I'd probably write out MachineBasicBlock instead of using auto here, as well. | |
167 | Don't bother getting a pointer here - just use the reference. | |
179 | Might be more readable to use the early-continue style in all these conditions, ie: if (MI.getOpcode() != TargetOpcode::COPY) continue; (Feel free to leave as is if that doesn't actually make it more readable) | |
180 | This isn't used until after the next condition, best to move it down. |
Updated based on Justin's feedback.
@qcolombet , I'm not sure if it always makes sense to propagate the register class information for all copies and replacing before the select hook for COPY. For all you know the target may want to do something special with the COPY.
LGTM too. The code is probably simpler to understand like this and if compile-time turns out to be a problem we can revisit.
I wonder though if removing this copies upfront wouldn't have helped tablegen current matching table (because it does not look through COPYs right now).
I certainly suspect somehow eliminating these copies upfront will result in tablegen matching patterns more deeply. I wonder if adding another step inside GIM_Try to also walk through copies is too much of a compile time increase as compared to a quick run before ISel removing redundant copies.
Why are you calling this MBI? It's a "MachineBasicBlock &", so it should really just be called MBB. I'd probably write out MachineBasicBlock instead of using auto here, as well.