[llvm-commits] [patch] Convert uses of getPhysicalRegisterRegClass in VirtRegRewriter.cpp
Jakob Stoklund Olesen
stoklund at 2pi.dk
Sun Jul 11 19:39:59 PDT 2010
On Jul 11, 2010, at 7:22 PM, Rafael Espindola wrote:
>> Your other patch removing the virtual specifier on getPhysicalRegisterRegClass is also OK to commit now, but you might just want to go ahead and remove the method entirely instead.
>
> Now there is one last use. It is in AggressiveAntiDepBreaker.cpp, but
> I am not sure how to replace it.
>
> If I understand the code correctly, it is trying to replace a hard
> register and assumes that any register in the class returned by
> getPhysicalRegisterRegClass can be used. This looks like a bug: an
> instruction might be using the current register and only accept a
> subclass of the one returned by getPhysicalRegisterRegClass.
I agree. That register had better not be used by TCRETURNri for instance.
> Using getMinimalPhysRegClass should be correct, but very conservative.
Yes.
> It is possible that the current register is used only in instructions
> that would accept registers from a larger classes. Unfortunately "make
> check-lit" found no such cases :-(
It might not notice unless you also assemble the output, or run with -verify-machineinstrs.
> The correct solution is probably to look at every instruction using
> that particular register and get the largest class that can be used in
> all those contexts.
Yes.
> Is the analysis correct or am I misunderstanding how
> AggressiveAntiDepBreaker works?
Your analysis is correct given the premises. I am not too sure how AggressiveAntiDepBreaker works either.
I am going to be adding some code that can infer the largest legal register class for a register given its uses. Such an algorithm can relieve register pressure when splitting live intervals.
Until then, I think the conservative getMinimalPhysRegClass is the right choice.
/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/20100711/14f2cfc6/attachment.bin>
More information about the llvm-commits
mailing list