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 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
When compressing the deoptimization info, suffixes of length one are not
shared (the compression is the same length as the original, but more
indirect). However, they were grafted onto the trie as if they were shared,
i.e., one level lower than they should be.
Add debug code to verify the compression/decompression round trip.
BUG=dartbug.com/13273
R=fschneider@google.com
Review URL: https://codereview.chromium.org//23788012
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27602 260f80e4-7a28-3924-810f-c04153c831b5
This CL is the first step in enabling full inlining of == calls.
Previously, calls to any function with the name "==" were not considered
for inlining because super-calls were not handled correctly. Instead
of implementing == semantics for super calls in the back-end, the parser
now expands super calls to == into
let t1 = left, t2 = right {
(t1 === null || t2 === null) ? t1 === t2
: static_call(super.==, t1, t2)
}
This change removes a bit of platform-specific assembly. Normal instance calls
to == are still translated as before. Expanding those at the AST level would
incur a too high cost in terms of (unoptimized) code size, and also would be
an obstruction for optimizations of equality. The plan is to expand those
only at optimization time if there is an inlineable instance call to ==.
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//23627009
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27248 260f80e4-7a28-3924-810f-c04153c831b5
Until now, we skipped regular code generation for some intrinsics
because the body was unreachable (no slow case).
With inlining and optimizing those methods, we may need the
unoptimized code for deoptimization support. Instead of deciding
case-by-case which of these methods may potentially deoptimize,
we always generate the full unoptimized code now, together
with the corresponding deoptimization info.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//22866025
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@26703 260f80e4-7a28-3924-810f-c04153c831b5
This is a first step towards fully optimizing try-catch-finally.
At a catch entry, all local variables and parameters are
expected at a fixed stack location. There is a list of
initial definitions at the catch entry block, similar to
the initial definitions at graph entry.
Inside every try-block there is a special prologue code before each
call (instruction that may throw) inside the try-block. This prologue
is similar to a parallel move instruction: It moves all locals+parameters
to the locations expected by the catch-entry block. The stack frame
is extended with the corresponding number of fixed slots right below
the normal spill slots.
Every function containing try-catch has additional compiler-
generated local variables to pass the context, the exception and
the stack trace.
Variable liveness analysis is adapted to treat locals inside try{} blocks
specially: Every call has an implicit LoadLocal of every local variable.
This CL uses a safe approximiation of liveness which can be optimized further.
Current restrictions which are planned for future CLs:
* No inlining inside try-blocks.
* No inlining of functions containing try-catch.
* No try-finally yet.
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//14682020
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@22615 260f80e4-7a28-3924-810f-c04153c831b5
AllocationSinking pass discovers non-escaping allocations that have no input uses other than uses in the stores into its own fields.
Every environment use of such allocation is replaced by a state snapshot (MaterializeObject instruction) that describes the state of each initialized field in the object. State snapshots are computed through an additional round of load-forwarding.
Once snapshots are computed allocations are removed from the graph.
MaterializeObject instructions are not compiled into native code but produce deoptimization instructions instead that describe how object should be materialized at deoptimization.
Deoptimization instructions now follow the following format:
[mat obj #1]...[mat obj #N][ret addr][... mat arguments ...][... real frames ...]
- the prefix describes each object to materialize on deopt via kMaterializeObject instruction;
- actual values that are needed for materialization are emited as a part of bottom-most stack frame. This is done to simplify implementation: they need to be discoverable by a GC during materialization phase. At the end of deoptimization they will be removed from the stack;
- normal stack slots can refer to materialized objects via kMaterializedObjectRef instruction.
Additionally this change contains fixes in load-forwarding that are needed to guarantee that all artificial LoadField instructions inserted during AllocationSinking are correctly replaced with actual values.
Limitations of the current implementation:
- can't eliminate allocations that flow into phis but otherwise don't actually escape;
- can't sink allocations out of loops;
- allocation with type arguments are not handled.
R=regis@google.com, srdjan@google.com, zra@google.com
Review URL: https://codereview.chromium.org//14935005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@22485 260f80e4-7a28-3924-810f-c04153c831b5
Remove representation from location. Presence of representation in location encoding was violating the invariant that unequal locations must be disjoint (where equality for locations is defined in terms of bitwise equality of their encoding). This could lead ParallelMoveResolver to treat XMM1 containing unboxed double as unequal location to XMM1 containing unboxed mint, which is obviously incorrect.
For similar reason eliminate kFloat32x4StackSlot and kUint32x4StackSlot distinction is eliminated and both are replaced with kQuadStackSlot. Register allocator now guarantees that no kQuadStackSlot occupies the same space as any other kDoubleStackSlot. This also shrinks optimized stack when only doubles are used (but might lead to a higher stack utilization when a mixture of doubles and quads is used).
Implement allocation of scratch Cpu and Xmm registers for ParallelMoveResolver. This also allows to remove push(eax)/pop(eax) pairs when resolving memory-memory cycles on ia32.
BUG=dart:9710
Review URL: https://codereview.chromium.org//13801014
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@21148 260f80e4-7a28-3924-810f-c04153c831b5
This CL provides inline IL code for the getters _getInt8, _getInt16, etc.
to speed up [] and byte array views.
The code uses the existing LoadIndexed instructions by passing a index
scale factor explicitly: For normal arrays loads, the scale factor is equal
to the element size. For byte array access, the scale factor is always 1.
I'm adding inlined setters in a separate CL.
Review URL: https://codereview.chromium.org//12218008
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@18173 260f80e4-7a28-3924-810f-c04153c831b5
Fix decoding of the deoptimization info when constructing a stack trace.
Fix stack trace for checked mode exceptions from optimized code.
BUG=dart:8058
TEST=runtime/tests/vm/dart/optimized_stacktrace_test.dart,
tests/language/stack_overflow_stacktrace_test.dart
Review URL: https://codereview.chromium.org//12049039
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@17755 260f80e4-7a28-3924-810f-c04153c831b5
fschneider@google.com