Until now the parser marked native functions as native when parsing.
This may be too late for some functions. E.g. the native typed list
constructor may not be invoked because the intrinsic code is executed
instead (unless for example new-space allocation fails).
This causes missing type information when optimizing functions using
those recognized factory functions like Uint8List._new.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//99373002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@30846 260f80e4-7a28-3924-810f-c04153c831b5
being generated for the observatory.
- Reset the state that a class is being currently parsed.
- Move the deployed polymer app to a location where it is not
being overwritten by the tools.
- Do not rely on Dart SDK binaries being in your path.
- Check for errors when invoking dart2js as part of build.dart.
Review URL: https://codereview.chromium.org//77043010
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@30533 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 inlining implicit getters via the polymorphic inliner
(and not through the flow graph optimizer) the fields loaded
must be added to the list of guarded fields that trigger
deoptimization when a store violated the field type guard.
Also, this CL avoids adding fields to the list from inlining
candidates that do not get inlined after all. Previously, the
optimizer pass on the callee graph would add guarded fields
even if the final graph does not get inlined.
TEST=tests/language/vm/optimized_guarded_field_test.dart
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//24096018
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27655 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
1. When comparing numbers, or strict-comparing objects, this can be folded into
true/false. Since this often occurs after inlining and store-to-load forwarding,
constant propagation is repeated after these phases. The pattern looks like:
o.x = o.y;
if (o.x == o.y) { ... }
2. Load elimination may introduce new phis that may have smi-type. In order to
get range information for these phis, I added a second phase of type propagation after
load elimination.
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//16813002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@23901 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
Prior to this change the initial heap sizes were as follows:
ia32:
Size of isolate snapshot = 1230921
New space (0k of 32768k) Old space (1446k of 1604k)
X64:
Size of isolate snapshot = 1223943
New space (0k of 32768k) Old space (2630k of 2692k)
After this change the initial heap sizes are as follows:
ia32:
Size of isolate snapshot = 686443
New space (0k of 32768k) Old space (677k of 836k)
X64:
Size of isolate snapshot = 684731
New space (0k of 32768k) Old space (1220k of 1412k)
R=hausner@google.com, iposva@google.com, regis@google.com
Review URL: https://codereview.chromium.org//14820028
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@23115 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
asiva@google.com