More compilation performance tuning
A man walks into a doctor's office and says:
"Hey Doc, it hurts when I do this"
Doc says:
"Then don't do that"
...
Although the last round of tuning the dataflow analsis code
resulted in a large speedup, we are still faced with a
significant number of (primarily initializer) methods which
blow up into a large number of basic blocks. We spend
much time and memory uselessly analyzing these (both because
they aren't run enough to matter, and even if they were, there
isn't much optimization we can do).
This CL attempts to recognize such methods, and skips the
most expensive analysis. The worst-case application that
we've been looking at gets a 35% boost in compilation speed,
but perhaps more significantly, the compiler's peak heap
usage drops from 370M to 162M. (Note: even 162M is much too
high - I'll be looking at further reducing worst-case memory
usage next).
Change-Id: I93cd15c846043cf46860afa562957921fc2de464
diff --git a/src/compiler/Dataflow.h b/src/compiler/Dataflow.h
index e810e52..cd2b1cb 100644
--- a/src/compiler/Dataflow.h
+++ b/src/compiler/Dataflow.h
@@ -106,6 +106,7 @@
#define DF_B_IS_REG (DF_UB | DF_UB_WIDE)
#define DF_C_IS_REG (DF_UC | DF_UC_WIDE)
#define DF_IS_GETTER_OR_SETTER (DF_IS_GETTER | DF_IS_SETTER)
+#define DF_USES_FP (DF_FP_A | DF_FP_B | DF_FP_C)
extern int oatDataFlowAttributes[kMirOpLast];