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
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
The AST for static getters differs between parsing the first time, and
subsequent parsings. This leads to a mismatch in deoptimization-ids
between the optimized and the unoptimized code.
This CL avoids creating different ASTs for the same static getters. To allow
better inlining of these getters, the initialization expression is wrapped in a
hidden static initializer-function. As a result the size of such getters is
constant and does not depend on the initializer expression.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//51123003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@29680 260f80e4-7a28-3924-810f-c04153c831b5
Branches that have the same true/false target, or where both
target blocks reach the same common join block via empty blocks
can be replaced by a goto to the common join block.
In code like this
var a = unknown();
var b = null;
if (a == null || b == null) {
...
}
it eliminates the test (a == null) if b is known to be null. Until now,
the compiler could only eliminate the test for b, if a was known.
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//23549020
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@28050 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
Update VM to latest spec. Referencing a name that is imported
from more than one library is no longer a compile-time error.
If one of the sources of an ambiguous reference is a dart library,
the dart library declaration is automatically hidden.
Also fixes a bug where looking up a getter name in a library
found the getter even though the name is filtered out in the
'hide' combinator.
Long-term we should fix the need for repeatedly convert between
the mangled getter and setter names and the untangled name.
Fixes 12915, 12913, 12724.
R=regis@google.com
Review URL: https://codereview.chromium.org//23484020
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27312 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
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
Add test.
Update status files.
Explanation of change: A malbounded type argument should not be mapped to
dynamic, as is a malformed type argument.
This change also adds a bunch of TODOs related to the encounter of malbounded
types in unexpected places.
A follow-up change will address these TODOs, add more tests, and may simplify
code that is still handling malformed types where they cannot occur anymore
after the spec simplified their handling.
R=hausner@google.com, srdjan@google.com
Review URL: https://codereview.chromium.org//23190035
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@26665 260f80e4-7a28-3924-810f-c04153c831b5
The optimizing compiler currently recognizes a certain frequent native methods
like array length or string length and provides an inlined implementation.
Inlining does currently not work for polymorphic call sites of these methods.
This CL enables also polymorphic inlining in the case of .length getters for
arrays and strings.
1. The method is recognized at flow graph build time. The builder creates
the body of the method for both compilers (non-optimizing and optimizing).
Native methods that are not recognized, are translated as before using a NativeCall
IL instruction.
2. The flow graph inliner handles recognized methods in the same manner as normal methods.
Until now intrinsic and recognized method could not be inlined. This CL enables it.
3. There is no need for an intrinsic assembly implementation because recognized methods
have an IL implementation that does not call into the C++ runtime. I left the intrinsics
in for now, but they can be removed if there is not noticable performance benefit anymore.
4. The inlining heuristics are tweaked in a way that enables more aggressive inlining
of recognized methods: +1 level of inlining depths, call sites of recognized methods are
not counted in the inlining heuristic.
R=kmillikin@google.com, srdjan@google.com
Review URL: https://codereview.chromium.org//22839003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@26429 260f80e4-7a28-3924-810f-c04153c831b5
Add profiling support to select OSR candidates and launch the compiler
for OSR, followed by entry to the function at the OSR entry point.
Implemented only on IA32 and X64. The initial implementation can be
improved in various ways --- specifically: tuning of profiling
parameters and incorporation of feedback about the actual values seen
at OSR entry.
R=fschneider@google.com
Review URL: https://codereview.chromium.org//16693006
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@24024 260f80e4-7a28-3924-810f-c04153c831b5
This CL affects a subset of expressions that use temporary locals: constructor
calls, array literals and and instance getter postfix-ops.
For expressions that are de-sugared in the parser I added LetNode.
It creates a scoped temporary local bound to an initializing expression.
For expressions where we need a temporary local at graph-building time,
I added a helper class TempLocalScope to easily create a single temporary
local in the graph builder since this is a frequently recurring pattern.
This simplifies code in the parser and the graph builder and also fixes a
bug with indexed-super invocation and NoSuchMethod.
BUG=dart:8918
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//14942010
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@23401 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
fschneider@google.com