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
Use the code's nesting to maintain the context level rather than explicitly
tracking it in the graph builder. Nested blocks know their scope and the
nesting stack can be searched to find the current context level.
Nested loops now increment and decrement the graph builder's loop depth
while they are on the nesting stack, though the loop depth state is still
kept in the graph builder itself.
R=fschneider@google.com
Review URL: https://codereview.chromium.org//63903005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@30397 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
In a static- or top-level variable v
var v = expr
static v = expr
If the initializer expression expr throws, the VM throws a
CyclicInitializationError when loading v afterwards, even though
this has nothing to do with cyclic initialization.
I'm changing the way implicit static getters and static initializers are
compiled. Static initializers are invoked from static getters.
They look as follows:
get:v {
if (field.value === transition_sentinel) {
field.value = null;
throw new CyclicInitializationError();
}
if (field.value === sentinel) {
field.value = transition_sentinel;
init:v();
}
return field.value;
}
init:v {
try {
field.value = expr;
} catch {
if (field.value === transition_sentinel) {
field.value = null;
}
rethrow;
}
}
BUG=http://dartbug.com/5802
TEST=language/lazy_static3_test,
language/throwing_lazy_variable_test,
co19/Language/12_Expressions/30_Identifier_Reference_A08_t02
R=hausner@google.com
Review URL: https://codereview.chromium.org//54713003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@29797 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
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
This CL adds the necessary parts to enable polymorphic
inlining of recognized methods. For now it handles only
[]-calls. This helps code that deals with e.g. growable
and fixed-length lists.
The basic idea is to adapt the code in the flow graph
optimizer so that it can be used from the generic inliner.
Currently this adds a bit of boilerplate code which I intend
to reduce when adding more recognized methods to be handled.
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org//23684059
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27627 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
The Name function is used for pretty printing except that for a few
node types we rely on a specific name for implementation correctness.
Overriding the pretty printing function to get out a type name, or a
variable name, or an operator symbol name, is risky.
1. Code that relies on the semantics of the name will break if the
pretty name is changed.
2. Pretty printing is less useful. For instance, LoadLocalNode just
prints the variable name (twice, once as the AST constructor and
once in quotes as the variable name). This is confusing if the
variable happens to have the same name as one of the other pretty
names, e.g., args or seq.
Now, there is a virtual function to get the pretty name but classes do
not change it to communicate other information (type names, variable
names, operator names).
BUG=
R=regis@google.com, srdjan@google.com
Review URL: https://codereview.chromium.org//23960003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27244 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
This works because I changed the compiler so that it always emit
the full unoptimized code for all intrinsic methods in a previous CL
As a result deoptimization works for those methods like for normal
methods.
Also, code for some recognized getter methods is moved to the flow
graph builder, so that there is no need for special handling in
the flow graph optimizer. This part of the change is
should be performance-neutral.
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//23756002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@26867 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
asiva@google.com