Move adding extra goto blocks to InlineInto
There are some cases in which we need to add extra goto blocks
when inlining to avoid critical edges. The `TryBoundary` of
`kind:exit` instructions will always have more than one successor
(normal flow and exceptional flow). If its normal flow successor
has more than one predecessor, we would be introducing a critical edge.
We can avoid the critical edge in InlineInto instead of doing it in
the builder which helps decoupling those two stages as well as
simplifying surrounding code.
We also have the benefit of adding the extra goto blocks only
when necessary.
Bug: 227283224
Test: art/test/testrunner/testrunner.py --host --64 --optimizing -b
Change-Id: Ibe21623c94c798f7cea60ff892064e63a38a787a
diff --git a/compiler/optimizing/builder.h b/compiler/optimizing/builder.h
index 145dbfb..ef225d9 100644
--- a/compiler/optimizing/builder.h
+++ b/compiler/optimizing/builder.h
@@ -47,7 +47,7 @@
const CodeItemDebugInfoAccessor& accessor,
DataType::Type return_type = DataType::Type::kInt32);
- GraphAnalysisResult BuildGraph(bool build_for_inline = false);
+ GraphAnalysisResult BuildGraph();
void BuildIntrinsicGraph(ArtMethod* method);
static constexpr const char* kBuilderPassName = "builder";
@@ -55,10 +55,6 @@
private:
bool SkipCompilation(size_t number_of_branches);
- // When inlining, we sometimes want to add an extra Goto block before the Exit block. This is done
- // in the building phase as we do not allow the inlining phase to add new instructions.
- void MaybeAddExtraGotoBlocks();
-
HGraph* const graph_;
const DexFile* const dex_file_;
const CodeItemDebugInfoAccessor code_item_accessor_; // null for intrinsic graph.