[turbolev] Add pre-pass to escape analysis [v8/v8 : main]
Darius Mercadier (Gerrit)
Darius Mercadier voted and added 1 comment![]( "Open in Gerrit")
Votes added by Darius Mercadier
| Auto-Submit | +1 |
Related details
- Victor Gomes
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Victor Gomes (Gerrit)
Victor Gomes added 4 comments![]( "Open in Gerrit")
bool has_exception_handler = false;This could be computed during graph building. As soon as we create an excetion block, we could mark this (if we move it to MaglevGraph)
// # Implementation
//
// Escape Analysis happens in 2 phases:
//
// * `CandidateAnalyzer` looks at the graph, computes which objects are
// escaping, and decides which objects to elide. It also computes the value
// of every field of elided objects at a given point of the program.
//
// * `Elider` actually removes the objects from the graph and update the nodes
// that reference them (in particular Stores and Loads, since those objects
// are guaranteed to not escape the current function).
//
//
// More implementation details & choices can be found in the design doc (linked
// at the top of the file).I guess you need to update that?
data_.candidates[alloc] = CandidateStatus::kCannotElide;
if (!alloc->HasBeenAnalysed()) {
alloc->SetEscaped();
} else {
DCHECK(alloc->HasEscaped());
}Idea for follow up: You could re-use HasEscaped bit in alloc if you want, instead of data_.candidates. Or add a new field in InlinedAllocations. This removes the data_.candidates completely, right?
This would make this processor completely detach from the rest of the escape analysis and we can put it in any place we want in the pipeline.
GraphProcessor<AnalyzerPrePass> prepass(data_);
prepass.ProcessGraph(data_.graph);Add a TODO, we could run the processor together with the previous pass (like together with an optimizer pass), since it is quite simple. It depends where we put the escape analysis in the end.
Related details
- Darius Mercadier
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Darius Mercadier (Gerrit)
Darius Mercadier added 4 comments![]( "Open in Gerrit")
bool has_exception_handler = false;This could be computed during graph building. As soon as we create an excetion block, we could mark this (if we move it to MaglevGraph)
Exception handlers can become unreachable in which case they shouldn't block escape analysis. I guess that once we move the prepass to the previous phase it won't matter anyways that we recompute this since it's very cheap.
(also, exception handlers blocking escape analysis should really be a very temporary state that I'm planning on fixing some times soon... although I'm not sure that "soon" is "this year" 😄)
// # Implementation
//
// Escape Analysis happens in 2 phases:
//
// * `CandidateAnalyzer` looks at the graph, computes which objects are
// escaping, and decides which objects to elide. It also computes the value
// of every field of elided objects at a given point of the program.
//
// * `Elider` actually removes the objects from the graph and update the nodes
// that reference them (in particular Stores and Loads, since those objects
// are guaranteed to not escape the current function).
//
//
// More implementation details & choices can be found in the design doc (linked
// at the top of the file).I guess you need to update that?
Done
(and updated the doc and added the performance numbers to the doc)
data_.candidates[alloc] = CandidateStatus::kCannotElide;
if (!alloc->HasBeenAnalysed()) {
alloc->SetEscaped();
} else {
DCHECK(alloc->HasEscaped());
}Idea for follow up: You could re-use HasEscaped bit in alloc if you want, instead of data_.candidates. Or add a new field in InlinedAllocations. This removes the data_.candidates completely, right?
This would make this processor completely detach from the rest of the escape analysis and we can put it in any place we want in the pipeline.
Yes good idea. For the prepass this could remove candidates indeed. For the main analysis, eventually I'm considering making candidates a SnapshotTable so that I can do allocation sinking, so I'd still need it. But that's far away.
I've incorporated this in the new TODO that you recommended below.
GraphProcessor<AnalyzerPrePass> prepass(data_);
prepass.ProcessGraph(data_.graph);Add a TODO, we could run the processor together with the previous pass (like together with an optimizer pass), since it is quite simple. It depends where we put the escape analysis in the end.
- Victor Gomes
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Victor Gomes (Gerrit)
Victor Gomes voted and added 1 comment![]( "Open in Gerrit")
Votes added by Victor Gomes
| Code-Review | +1 |
| Commit-Queue | +2 |
1 comment
Related details
- Darius Mercadier
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
v8-scoped@luci-project-accounts.iam.gserviceaccount.com (Gerrit)
v8-s...@luci-project-accounts.iam.gserviceaccount.com submitted the change![]( "Open in Gerrit")
Change information
[turbolev] Add pre-pass to escape analysis
This CL adds a very quick pre-pass to escape analysis that allows to
not run the expensive analysis for cases where all allocations
eventually escape.
This reduces the time that we spend in escape analysis by 1.34x on
average on JetStream3, and the average improvement on JS3 line items
is 2.03x and the median 1.46x (talking about time spent in escape
analysis again, not about score!). In terms of raw data, on my
workstation this saves about 60ms of compile time on JS3.
- M src/maglev/turbolev-escape-analysis.cc
- M src/maglev/turbolev-escape-analysis.h
Code-Review: +1 by Victor Gomes
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |