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

Rafael Espindola espindola at google.com
Sat Jun 12 21:36:29 PDT 2010


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

> /jakob


Cheers,
-- 
Rafael Ávila de Espíndola




More information about the llvm-commits mailing list