diff options
| author | Evgeny Astigeevich <evgeny.astigeevich@linaro.org> | 2020-06-12 10:51:43 +0100 |
|---|---|---|
| committer | Nicolas Geoffray <ngeoffray@google.com> | 2020-06-17 08:00:58 +0000 |
| commit | 6587d9110bd7f836e43db16f3f676da996218aef (patch) | |
| tree | 437d06a8e60fd70aaafaf2b167dfe636a303c68a /compiler/optimizing/optimizing_compiler.cc | |
| parent | 1912a5c7b9400009e361b0db52da77cc78f1cd77 (diff) | |
ART: Simplify HRem to reuse existing HDiv
A pattern seen in libcore and SPECjvm2008 workloads is a pair of HRem/HDiv
having the same dividend and divisor. The code generator processes
them separately and generates duplicated instructions calculating HDiv.
This CL adds detection of such a pattern to the instruction simplifier.
This optimization affects HInductionVarAnalysis and HLoopOptimization
preventing some loop optimizations. To avoid this the instruction simplifier
has the loop_friendly mode which means not to optimize HRems if they are in a loop.
A microbenchmark run on Pixel 3 shows the following improvements:
| little cores | big cores
arm32 Int32 | +21% | +40%
arm32 Int64 | +46% | +44%
arm64 Int32 | +27% | +14%
arm64 Int64 | +33% | +27%
Test: 411-checker-instruct-simplifier-hrem
Test: test.py --host --optimizing --jit --gtest --interpreter
Test: test.py --target --optimizing --jit --interpreter
Test: run-gtests.sh
Change-Id: I376a1bd299d7fe10acad46771236edd5f85dfe56
Diffstat (limited to 'compiler/optimizing/optimizing_compiler.cc')
| -rw-r--r-- | compiler/optimizing/optimizing_compiler.cc | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/compiler/optimizing/optimizing_compiler.cc b/compiler/optimizing/optimizing_compiler.cc index 45d31bad79..8d4aa9fd5d 100644 --- a/compiler/optimizing/optimizing_compiler.cc +++ b/compiler/optimizing/optimizing_compiler.cc @@ -643,7 +643,7 @@ void OptimizingCompiler::RunOptimizations(HGraph* graph, // Simplification. OptDef(OptimizationPass::kConstantFolding, "constant_folding$after_bce"), - OptDef(OptimizationPass::kInstructionSimplifier, + OptDef(OptimizationPass::kAggressiveInstructionSimplifier, "instruction_simplifier$after_bce"), // Other high-level optimizations. OptDef(OptimizationPass::kSideEffectsAnalysis, @@ -656,7 +656,7 @@ void OptimizingCompiler::RunOptimizations(HGraph* graph, // The codegen has a few assumptions that only the instruction simplifier // can satisfy. For example, the code generator does not expect to see a // HTypeConversion from a type to the same type. - OptDef(OptimizationPass::kInstructionSimplifier, + OptDef(OptimizationPass::kAggressiveInstructionSimplifier, "instruction_simplifier$before_codegen"), // Eliminate constructor fences after code sinking to avoid // complicated sinking logic to split a fence with many inputs. |