Page MenuHomePhabricator

[ImplicitNullCheck] Hoisting multiple dependencies

Authored by anna on Sep 10 2020, 7:13 PM.



This patch introduces a new dependence tracking mechanism for the
faulting operation, wherein multiple dependencies can be tracked. This
allows us to hoist a list of dependencies along with the faulting memory
We now catch some of the existing testcases with multiple
dependencies as well as some newly added testcases.
The key point to note is that by the time we reach dependency tracking,
we have already completed two other important sections for safety
analysis, namely isSuitableMemoryOp and whether unsafe instructions
modify PointerReg (i.e. those that do not preserve zero value of the

Diff Detail

Event Timeline

anna created this revision.Sep 10 2020, 7:13 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 10 2020, 7:13 PM
anna requested review of this revision.Sep 10 2020, 7:13 PM
dantrushin added inline comments.Sep 19 2020, 11:22 AM

Would be great to have a brief comment about what's 'safe' dependence is.


You say about explicit uses, but do not have corresponding check.
MI->uses() includes everything except explicit defs. Do you want to use MI->explicit_uses() here?


Move this check to the top of loop? (Before canReorder() check)


Er, are you checking defs of CurrMI? Would CurrMI->defs() work here (if you're checking explicit defs only)?
Or loop over TrackedRegisterUSes using CurrMI->modifiesRegister() as predicate?

anna abandoned this revision.Nov 3 2020, 8:28 AM

may revisit later.