[PATCH][regalloc] Fix the interference calculation for register masks.

Jakob Stoklund Olesen jolesen at apple.com
Wed Nov 13 13:13:45 PST 2013


On Nov 13, 2013, at 9:57 AM, Quentin Colombet <qcolombet at apple.com> wrote:

>> If an instruction has a normal (r slot) def biased toward %rax and a dead def of %rax, can the normal def be assigned to %rax?
>> 
>> The situation is an intrinsic call returning its value in a vreg.
>> 
>> %vreg0 = PATCHPOINT regmask(~%rax, …)
>> %rax = copy %vreg0
>> return
>> 
>> The way I see it, the regmask clobbers exist somewhere between the use’s ‘r’ slot and the def’s ‘r’ slot. We don’t have a slot for that :)
> I agree with both the definition and the fact we are lacking this semantic.
> To be honest, before Jakob clarification, I thought the regmask has the between uses and defs semantic and that dead-defs were explicitly modeled with dead register definitions.
> 
> I am surprised we haven’t seen that problem before, because calls should have the exact same problem for return value. Indeed, return values are both defined and clobbered by calls. I guess we did not see that because for calls the definitions were physical registers, thus no need to allocate them.
> 
> Sorry if I sound like captain obvious.

Not at all.

The current liveness model doesn’t distinguish between defs and clobbers. They basically happen simultaneously.

A function return value normally goes in a fixed register, so if that register is also clobbered by a regmask, it essentially looks like two defs/clobbers of the same physreg. The register allocator doesn’t mind that - you obviously knew what you were doing when you built that instruction. However, the register allocator will never allocate a virtual register so it overlaps a def/clobber.

There is nothing wrong with distinguishing defs from clobbers, but there simply hasn’t been a need so far.

Thanks,
/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131113/2d353722/attachment.html>


More information about the llvm-commits mailing list