This CL has no change in functionality and is purely clean up and
refactoring. Instead of manually generating the moves at throwing
instructions in try-catch, construct a parallel move and use the resolver
to emit the native code. This eliminates a lot of duplicated code
from all platforms.
It will also allow to re-use stack space that is currently allocated
separately for each individual try-catch in a function.
I added a few more unrelated minor changes in various parts of the VM
* Simpilify guard code generation
* Resolve refactoring TODO in deoptimization
* Improve names
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org//119213002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@31326 260f80e4-7a28-3924-810f-c04153c831b5
This allows the optimizing compiler to generate unboxed loads/stores
to fields containing double values. The double value is stored
in a reusable double object.
Unboxed loads/stores are generated for optimized code. Unoptimized code
allocates a new double on loads. To avoid performance regressions
for fields that are only written few times (e.g. only in the constructor)
I put a heuristic in place that
compares the usage count of setters and getters. Unboxed operations
are only generated if the setter is invoked a significant amount of
times (threshold is 10% of getter invocations).
The CL is so big because it changes the way LocationSummmary
is allocated: We now have a bit to generate different summaries
for optimized and unoptimized code.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//99573005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@31164 260f80e4-7a28-3924-810f-c04153c831b5
This is another refactoring step. It turn all comparisons
to be generated after the same pattern and removes duplicated
code from each of the different comparisons (smi, mint, double, etc.)
A comparison as an expression now follows the same patterns as a comparison
inside a branch. It just adds a common epilogue to materialize the boolean
result.
In another CL this common epilogue will be generated by reusing the IfThenElse
IL instruction.
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//64483002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@30243 260f80e4-7a28-3924-810f-c04153c831b5
This CL is the first step in refactoring the way branches and comparisons
are generated.
1. Move helper functions from flow_graph_compiler_xyz.cc to
intermediate_language_xyz.cc.
2. Remove IL class ControlInstruction. It was only implemented by BranchInstr.
All functions provided are moved to BranchInstr.
3. When generating branch code for comparisons, pass the successor labels explicitly
instead of getting them from the branch. This will allow us to provide different labels
when materialize a bool value of a comparison.
4. Move some common code for IfThenElseInstr from the platform-specific files
into intermediate_language.cc and simplify it.
The goal is to enable if-conversion of arbitrary comparisons. Right now,
the code for == is hard-coded in IfThenElseInstr (and duplicated, too). This
means that e.g. "a < b ? 0 : 1" cannot be optimized.
As a result, IfThenElseInstr can be used to materialize the boolean value of
a comparison. This way the complication of having ComparisonInstr both as a
normal instruction and as wrapped inside a BranchInstr can be simplified.
Comparisons would no longer appear as plain instructions in the IL, but only
wrapped inside either a Branch or an IfThenElse(true, false).
R=zra@google.com
Review URL: https://codereview.chromium.org//62133002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@30042 260f80e4-7a28-3924-810f-c04153c831b5
In unoptimized code equality is now just another instance call.
The optimizer replaces it with a specialized implementation based on static
type information and type feedback.
Many of the manual optimizations of == in the optimizer are now just handled
by the generic inliner, plus polymorphic inlining of == calls is now possible.
This also eliminates the need for a lot of duplicated code in the backend.
I adapted the inlining heuristics to compensate for the slightly larger
inital flow graph size.
Review URL: https://codereview.chromium.org//27307005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@29800 260f80e4-7a28-3924-810f-c04153c831b5
By inserting the necessary checks for null inside the callee
at the AST level, the code generation of == operations can be
greatly simplified.
This is a performance-neutral change and a step for allowing
generic inlining of arbitrary == methods. So far we could only
inline them for a common set of types in the flow graph
optimizer.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//24203004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@28084 260f80e4-7a28-3924-810f-c04153c831b5
Instead of having a separate IL instructions relational comparisons
are built as normal instance calls initially. When optimized, we replace
the instance call with a smi/double/mint comparison instruction.
This enables generic inlining of relational operator calls and simplifies
code generation, too.
Merging comparisons with branches is done in the optimizing compiler's
branch simplification phase.
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//23757016
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27058 260f80e4-7a28-3924-810f-c04153c831b5
The IsPowerOfTwo function is used together with ShiftForPowerOfTwo. Both function
do not work with zero. This caused the optimizing compiler to generate invalid code
for the expression
x ? 0 : 0
where it assumed that if one of the constants is a power-of-two, it can
be computed by (1 << n). We check for 0 in a number of places, but instead
I decided to fix Utils::IsPowerOfTwo itself and remove unnecessary checks
for the zero case.
TEST=tests/language/vm/if_conversion_vm_test.dart, runtime/vm/utils_test.cc
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//23604024
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27033 260f80e4-7a28-3924-810f-c04153c831b5
In optimized code we can eliminate the allocation of closures that are not
escaping and where all calls are inlined.
Closures are currently allocated with a special IL instruction (CreateClosure).
This CL changes this for non-implicit closures and allocates them
like normal objects. The fields for the function and the context are
initialized like instance fields. This way object allocation sinking can
handle closures like any other objects.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//19370003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@25706 260f80e4-7a28-3924-810f-c04153c831b5
srdjan@google.com