| commit | fd5ff400e55fd6d3d0e99978f92b00b0698e3f82 | |
| author | Jan Oravec <jan@fb.com> | |
| Thu, 11 Oct 2018 23:09:33 +0000 (11 16:09 -0700) | ||
| committer | Hhvm Bot <hhvm-bot@users.noreply.github.com> | |
| Thu, 11 Oct 2018 23:11:56 +0000 (11 16:11 -0700) | ||
| tree | 1233ce3ed65750b7bf591bc8d0e658bc714da3c5 | treesnapshot (tar.gz zip) |
| parent | 3b16744724d01edd1b3a3a32b426b1bd1dc9b181 | commitdiff |
Fix DefInlineFP use update leak via InlineSuspend
Summary:
If there is a path from an InlineSuspend to its corresponding DefInlineFP, e.g.
because the caller calls the inlined callee in a loop, when pdce-inliner would
try to sink DefInlineFP out of the main blocks, it would try to recursively
update its uses, crossing InlineSuspend, reaching DefInlineFP and incorrectly
update main blocks with the newly defined DefInlineFP in its successors. Then
we would crash on attempts to unify FP.
Avoid this issue by not propagating the new FP beyond InlineSuspend opcodes.
Reviewed By: ricklavoie
Differential Revision: D10318321
fbshipit-source-id: 594b0ee41554c450c5bab8748c96b6a7d6a3dc31
Summary:
If there is a path from an InlineSuspend to its corresponding DefInlineFP, e.g.
because the caller calls the inlined callee in a loop, when pdce-inliner would
try to sink DefInlineFP out of the main blocks, it would try to recursively
update its uses, crossing InlineSuspend, reaching DefInlineFP and incorrectly
update main blocks with the newly defined DefInlineFP in its successors. Then
we would crash on attempts to unify FP.
Avoid this issue by not propagating the new FP beyond InlineSuspend opcodes.
Reviewed By: ricklavoie
Differential Revision: D10318321
fbshipit-source-id: 594b0ee41554c450c5bab8748c96b6a7d6a3dc31
| hphp/runtime/vm/jit/pdce-inlining.cpp | diffblobblamehistory |