The ZERO register should be exposed as a constant physical register through the interface TargetRegisterInfo::isConstantPhysReg.
Details
Diff Detail
Unit Tests
Event Timeline
While this is certainly correct, I am curious what prompted the change. Did it cause a test case failure somewhere? Did it prevent some optimization? If either of those is the case, I imagine we can produce a test case for this patch.
I'm working on https://reviews.llvm.org/D130919#change-i79krRTVIqHY.
Function MachineRegisterInfo::isConstantPhysReg returns true for a physical register if it satisfies
- It is a target specific constant register and
- It is not modified in the current function.
But it only checks defined register operands. A physical register may also be clobbered by a RegMask(function call). So my patch adds checking agains regmasks.
This patch causes f128-aggregates.ll failed. The problem is in MachineCSE pass, when it checks if the following instruction can be CSEed,
%22:vsrc = LXVD2X $zero8, %13:g8rc :: (load (s128) from constant-pool)
A physical register $zero8 is used, then it checks if $zero8 is constant through MachineRegisterInfo::isConstantPhysReg. Because it is not marked as target specific constant register, it continues to check if it is modified in the function. $zero8 is not used as defined register operand, so the original MachineRegisterInfo::isConstantPhysReg returns true for it. But now we also consider RegMask clobbered register. There is a function call in the test, $zero8 is not marked as callee saved register(this is another problem), so now $zero8 is modified by a RegMask, and MachineRegisterInfo::isConstantPhysReg returns false for $zero8.
This patch can fix the failure.
I'd prefer if this wasn't committed and we used my change to auto-generate this method from tablegen (D131962) instead.