Bug 206041 - We should consider changing where we merge LocalHeaps in our fixpoint LocalHeap analysis inside ObjectAllocationSinking
Summary: We should consider changing where we merge LocalHeaps in our fixpoint LocalHe...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Saam Barati
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-09 17:07 PST by Saam Barati
Modified: 2020-01-10 13:32 PST (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Saam Barati 2020-01-09 17:07:46 PST
...
Comment 1 Yusuke Suzuki 2020-01-10 13:32:48 PST
BTW, I was considering about Object-Allocation-Sinking’s changed condition further, and now I think after third-iteration, we can just use the original check (instead of checking changed for each successor’s merging).
`changed` status check was wrong in first and second iteration because,
1. In the first iteration, we are not collecting all the pointers yet. So the invariant, “If the heap of predecessors are not changed, the current block’s heap is not changed” is not met.
2. In the second iteration, we already collected all the pointers. However, we decide whether it is changed by comparing the current Heap and the heap calculated in the first iteration. And the heap calculated in the first iteration is still breaking the invariant described in the (1). So, wrong.
3. In the third iteration, calculated heap, and the stored heap are all meeting the invariant described in (1). So, it is safe.

So, we can avoid any checks in the first, second iterations. And after that, we can start third iteration which actually starts calculating it for each block, and it should be sufficient.