We're creating a new copy here and I think all that's important is that the result of the copy satisfies the instruction that's using it. The register we're copying from may have been overconstrained by the requirements of other users and we don't need to keep those constraints if we're making a copy.
I observed this when I tried to remove the explicit copies in X86InstrCompiler.td
def : Pat<(i8 (trunc GR32:$src)), (EXTRACT_SUBREG (i32 (COPY_TO_REGCLASS GR32:$src, GR32_ABCD)), sub_8bit)>, Requires<[Not64BitMode]>; def : Pat<(i8 (trunc GR16:$src)), (EXTRACT_SUBREG (i16 (COPY_TO_REGCLASS GR16:$src, GR16_ABCD)), sub_8bit)>, Requires<[Not64BitMode]>;
The EXTRACT_SUBREG handling in InstrEmitter.cpp should make these unnecessary by constraining the register class for the input to COPY that does the extract or emitting a new COPY before the extract. If it uses the constraint, then that constraint can be propagated to the result of a COPY introduced by the two address instruction pass.
Unfortunately, this seems to have broken a PowerPC test because there is a check in the pass to only handle COPY with the same source and dest class and the copy it was finding came from the two address instruction pass.
Can't this now fail if the instruction uses an unknown register class operand?