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
When nesting try-finally, the outer finally was incorrectly executed
twice under certain conditions (a return in the inner try-block and a outer
finally-block that ends with throw)
This was because finally-code was inlined at return/break/continue statements
and it was associated with the wrong catch-handler when compiling.
This CL tracks indices of try-blocks in the parser so that each inlined
finally block has the correct catch handler index.
BUG=https://code.google.com/p/dart/issues/detail?id=11972
TEST=test/language/throw8_test.dart
R=hausner@google.com
Review URL: https://codereview.chromium.org//22184003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@25767 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
This CL removes the remaining missing cases when inlining closure
calls.
In order to benefit for code using forEach, I added GrowableObjectArray.forEach
to the functions that should always be inlined.
I also renamed BuildLoadContext/BuildStoreContext helpers in the flow
graph builder to better match what they do.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//19721004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@25551 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
1. The result value of an expression
"super.someMissingSetter = val" was incorrect in case of a noSuchMethod call.
To fix this I refactored the BuildStaticNoSuchMethod function. It now no longer
creates AST nodes and visits them, because the last argument may be needed saved
as a result value.
2. The evaluation order of "super[e1] = e2" was wrong in case of a noSuchMethod call.
BUG=dart:8917, dart:10965
TEST=tests/language/super_operator_index7_test.dart, tests/language/super_operator_index8_test.dart
R=srdjan@google.com
Review URL: https://codereview.chromium.org//15979010
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@23553 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
Two parts:
1. Change AllocateObjectWithBoundsCheck to a normal call that takes
four arguments on the stack using PushArgument IL instructions.
Before inputs were in registers and the instruction pushed them itself
before the runtime call. This make the code more compact and simplifies
the flow graph builder.
2. Simplify instructions for building constructor type arguments for another
special case to simplify the instruction pattern and generate smaller
code for that case.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//15564004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@22943 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
- stores/loads that access different fields can't alias each other;
- if result of the AllocateObject does not escape then stores/loads to it does not alias stores/loads to other objects.
Other:
- rename LoadFieldInstr's value to instance to better convey meaning and match StoreInstanceFieldInstr;
- slightly bump inlining_size_threshold;
- canonicalize UnboxDouble(BoxDouble(v)) and BoxDouble(UnboxDouble(v)) patterns;
R=srdjan@google.com
BUG=
Review URL: https://codereview.chromium.org//14872002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@22340 260f80e4-7a28-3924-810f-c04153c831b5
instantiator of generic objects (fixes issue 10149).
This optimization considers the generic type argument vector of the instance
being allocated as well as the generic type argument vector of the compile
time type of the instantiator.
If the instance vector is a prefix of the instantiator vector, the instantiator
vector can be shared by the new instance.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//14106013
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@22155 260f80e4-7a28-3924-810f-c04153c831b5
johnmccutchan@google.com