This is an archive of the discontinued LLVM Phabricator instance.

Check for register clobbers when merging a vreg live range with a reserved physreg in RegisterCoalescer.
ClosedPublic

Authored by jyknight on Jan 10 2017, 12:10 PM.

Details

Summary

Previously, we only checked for clobbers when merging into a READ of
the physreg, but not when merging from a WRITE to the physreg.

Diff Detail

Repository
rL LLVM

Event Timeline

jyknight updated this revision to Diff 83849.Jan 10 2017, 12:10 PM
jyknight retitled this revision from to Check for register clobbers when merging a vreg live range with a reserved physreg in RegisterCoalescer..
jyknight updated this object.
jyknight added a reviewer: qcolombet.
jyknight added a subscriber: llvm-commits.

Makes sense, I am surprised this didn't hit us before.

Could you create a .mir based test that just runs the coalescer instead of the .ll one?

jyknight updated this revision to Diff 84126.Jan 12 2017, 8:19 AM

Added MIR test case to AArch64/regcoal-physreg.mir.

Makes sense, I am surprised this didn't hit us before.

Could you create a .mir based test that just runs the coalescer instead of the .ll one?

I noted the existing MIR test in AArch64/regcoal-physreg.mir, and added another test-case there.

I also noticed while writing this new test case that MachineRegisterInfo::isConstantPhysReg treats any register without a visible def in the function as "constant". And thus, the newly added test case doesn't work -- it will coalesce -- without the "%x18 = COPY %xzr" line.

I'm not sure this is correct behavior, since it *also* fails to take into account regmasks, but I also don't know if there's a situation where it would actually matter -- in the actual case I'm looking at, the inlineasm is a def of the register, so that's fine.

qcolombet added inline comments.Jan 12 2017, 2:40 PM
test/CodeGen/AArch64/regcoal-physreg.mir
77 ↗(On Diff #84126)

That sounds like a bug to me.
I would have expected the constant attribute to be decided by the target, i.e., not something that depends on the presence of a definition.

Could you investigate please?

MatzeB accepted this revision.Jan 12 2017, 5:46 PM
MatzeB added a reviewer: MatzeB.

LGTM
The "no-def+!allocatable => constant" rule has been there for a long time in MachineRegisterInfo::isConstantPhysReg(), not sure we need to check/question it as part of this commit...

This revision is now accepted and ready to land.Jan 12 2017, 5:46 PM
This revision was automatically updated to reflect the committed changes.
qcolombet edited edge metadata.Jan 13 2017, 4:14 PM

The "no-def+!allocatable => constant" rule has been there for a long time in MachineRegisterInfo::isConstantPhysReg()

Oh, I missed the !allocatable in the description of the problem.
Yeah, no need to investigate then.

llvm/trunk/test/CodeGen/AArch64/regcoal-physreg.mir
78

You could use something else than x18 to avoid the !allocatable case that Matthias mentioned, right?
What I am saying is that the comment is a bit misleading as it is, because this is expected when register are not allocatable.

jyknight added inline comments.Jan 15 2017, 8:12 PM
llvm/trunk/test/CodeGen/AArch64/regcoal-physreg.mir
78

The bug only exhibits for reserved registers in the first place (and only, then, if it is also clobbered by a call), so another register wouldn't be appropriate.