This is an archive of the discontinued LLVM Phabricator instance.

Keep dead inst copy from being deleted only when the inst is rematerializable
ClosedPublic

Authored by wmi on Apr 25 2016, 9:52 AM.

Details

Summary

The patch is to fix the two bugs reported here: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160418/349985.html

The fix is to allow the dead insts kept in DeadRemat only when they are rematerializable. Because isReallyTriviallyReMaterializableGeneric put many limits on rematerializable instructions, this fix can prevent instructions with tied virtual operands and instructions with virtual register uses from being kept in DeadRemat, so as to fix the problems in the report.

Also add the check "DeadRemat != nullptr" in the condition to put the dead insts in DeadRemat. Because for RegisterCoalescer, its DeadRemat is nullptr, and we want dead instructions in this phase to be eliminated normally.

Diff Detail

Repository
rL LLVM

Event Timeline

wmi updated this revision to Diff 54870.Apr 25 2016, 9:52 AM
wmi retitled this revision from to Keep dead inst copy from being deleted only when the inst is rematerializable .
wmi updated this object.
wmi added a reviewer: qcolombet.
wmi set the repository for this revision to rL LLVM.
wmi added subscribers: llvm-commits, davidxl, uabelho.
qcolombet edited edge metadata.Apr 25 2016, 2:30 PM

Hi Wei,

Additing the alias analysis seem unreleated to me.
Could it be a separate patch?
Could you add a test case?

Cheers,
-Quentin

lib/CodeGen/LiveRangeEdit.cpp
331 ↗(On Diff #54870)

Don't we already check that MI is triviallyReMaterializable before trying to rematerialize?
I.e., this is just an optimization to keep DeadRemats small, not the actual fix, right?

In other words, if this is the proposed fix, I think I miss something!

wmi added a comment.Apr 25 2016, 3:12 PM

Additing the alias analysis seem unreleated to me.
Could it be a separate patch?

Adding alias analysis is because isTriviallyReMaterializable will use it. I am not sure whether separating the alias analysis part will cause unused-var-warning.

Could you add a test case?

Ok, will do that.

Thanks,
Wei.

lib/CodeGen/LiveRangeEdit.cpp
331 ↗(On Diff #54870)

This patch is to fix the problems by keeping DeadRemats small.

For instruction like vreg1 = vreg2 + 3 which is not triviallyReMaterializable because it has a vreg use on rhs, if it is dead, previously we still put it in DeadRemats and fail to update the live interval after we delete it in postOptimization. This will cause verifier error.

Now we reduce the DeadRemats set to dead instructions which will truly possible to be used in rematerialization, we don't have to worry live interval update because instructions in DeadRemats won't have vreg use. vreg dest is a dummy register and its live interval has been properly set.

In other words, keep instructions in DeadRemats to a limited form enforced by triviallyReMaterializable, we can simplify some live interval update hassle and keep the machine verifier silent.

qcolombet added inline comments.May 13 2016, 9:41 AM
lib/CodeGen/LiveRangeEdit.cpp
331 ↗(On Diff #54870)

That sounds more like a workaround for a more general liveness problem.
Those instructions are not supposed to be there and they *must* not affect the liveness of other the variables referenced in those instructions.

That being said, I could live with the fact that we do not push instructions that we know we won’t be able to rematerialize. But, this should not be considered to be the fix for the other problem. In other words, we need to find a way to properly update the liveness when we kill, but keep those instructions.

wmi added inline comments.May 13 2016, 10:53 AM
lib/CodeGen/LiveRangeEdit.cpp
331 ↗(On Diff #54870)

Yes, in that sense, this is a workaround. I understand that suppose one day, we relax the constraints in triviallyReMaterializable and let more complex instructions become rematerializable, the problem will surface again. I will think about how to fix the problem.

wmi added a comment.Jul 6 2016, 5:05 PM

Quentin, Is it ok to checkin the workaround for now as it has no downside? I havn't got time to solve the essential problem yet, but I will find the time.

Thanks,
Wei.

Hi Wei,

Sure, if it is required to unblock some other stuff, go for it.
However, file a PR so that we remember to revert the related patch and do the proper fix.

Cheers,
-Quentin

This revision was automatically updated to reflect the committed changes.