[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.

TLI gets that directly from X86TargetLowering:

    addRegisterClass(MVT::f80, X86::RFP80RegisterClass);

This should not be called after stackification, only during isel. Who calls getRegClassFor() so late?

> 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.


getMaximalPhysRegClass(Reg, VT) is a possibility, but I think TLI.getRegClassFor(VT) fits.


-------------- 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/20100612/35ec7616/attachment.bin>