[llvm-commits] [llvm] r107529 - in /llvm/trunk: include/llvm/CodeGen/MachineInstr.h include/llvm/Target/Target.td include/llvm/Target/TargetOpcodes.h lib/CodeGen/LowerSubregs.cpp utils/TableGen/CodeGenTarget.cpp
Chris Lattner
clattner at apple.com
Sun Jul 4 21:29:15 PDT 2010
On Jul 4, 2010, at 3:20 PM, Jakob Stoklund Olesen wrote:
> On Jul 4, 2010, at 3:06 PM, Chris Lattner wrote:
>
>>> I also intend to change the copyRegToReg hook to only allow physical register arguments, and eliminate the register class arguments.
>>
>> Ok. By virtue of taking vregs, the new COPY instruction will have regclass info. I assume that COPY will also allow physregs, how will it (or will it?) represent regclass info for physregs?
>
> COPY allows physregs, and it holds no register class information in that case.
Ok, if it ends up really being important, we can probably figure out some way to extend it :)
> Knowing the actual physreg should be enough to choose the proper copy instruction. Only extremely exotic architectures like x86 will have trouble.
Meh, who uses X86 anymore?
> When copying an xmm register, x86 will be forced to use a movaps instruction instead of movss/movsd because register class information is not available. I don't think that is going to cause performance problems, but it might depending on the specific microarchitecture.
Yeah, I don't know enough about the domain crossing penalties. They may not affect movs?
> If a microarchitecture turns up where movaps is not the right choice, I would argue we need to model the xmm scalar sub-registers explicitly.
Right. It seems fairly straight-forward to give COPY a third argument, which would indicate the register class #?
-Chris
More information about the llvm-commits
mailing list