[llvm-commits] [patch] Mostly mechanical removal of getPhysicalRegisterRegClass.patch

[Jakob Stoklund Olesen]

On Jun 12, 2010, at 9:36 PM, Rafael Espindola wrote:

>> The first bit is in isel, creating virtregs for copying to and from a physreg. These all use the VT argument, and you should preserve that. It makes a difference if XMM1 is spilled as FR32, FR64, or VR128. In these cases, the physreg doesn't actually need to belong to the chosen class, and an argument could be made for using TLI.getRegClassFor(VT) instead. We want a compatible regclass to allow coalescing, but if coalescing is not possible, we want the largest possible regclass. In any case, you want a regclass compatible with VT.
> 
> I tested  TLI.getRegClassFor a bit and found an interesting case: f80.
> If I understand it correctly, the RST class is used after the
> stackfier has run. Since getRegClassFor has no idea if that has
> happened or not, it return a RFP80 and the backend get surprised by
> the reappearance of a RFP80.
> 
> This and your comment about wanting the largest available class,
> suggest that the current function might actually be the correct one in
> some places. We should be able to at least make it non virtual.

I think I was confused.

I have taken a closer look at InstrEmitter.cpp now. In EmitCopyFromReg(), getPhysicalRegisterRegClass() is only used to provide an argument for copyRegToReg(), and TLI->getRegClassFor(VT) is already used to create the virtual register.

That is fine as is. It is safe to replace getPhysicalRegisterRegClass with getMinimalPhysRegClass there.

The same goes for the uses in ScheduleDAG*.cpp

/jakob


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1929 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20100613/8b46db06/attachment.bin>