The stack slots of captured parameters must be skipped when
generating sync code in optimized try-catch. Since those parameters
are initially copied into the context, their values are not recorded
in the environment.
Store-to-load forwarding may though use the original initial value
from the stack and therefore it must not be overwritten by try-sync
code that predeeds every call inside optimized try-blocks.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//653073002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@41099 260f80e4-7a28-3924-810f-c04153c831b5
- Improve escape/alias analysis:
-- Storing an object into a field of another object does not mean that this object escapes (or has aliases) as long as that object does not have any loads from the same place;
-- Places like X.f and Y.f don't alias if X and Y are two different allocation instructions even if X and Y themselves potentially have aliases;
-- Improve precision of alias analysis for indexed properties;
- Support dematerialization and rematerialization of objects that are referenced by other dematerialized objects.
-- Use fix-point algorithm to collect candidates for allocation sinking;
-- Support aborting unsuccessful allocation sinking.
R=fschneider@google.com, johnmccutchan@google.com
Review URL: https://codereview.chromium.org//395943003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@38404 260f80e4-7a28-3924-810f-c04153c831b5
This optimization is the dual to load elimination. It uses
the same infrastructure for handling aliasing. Since dead
store elimination is a backward data-flow analysis it inherits
from LivenessAnalysis.
Instead of eliminating upward exposed loads, it eliminates
downward exposed stores.
First local intra-block analysis is done in ComputeInitialSets.
Afte the fixed point iteration EliminateDeadStores performs the
global optimization on downward exposed stores in each block.
Only fully dead stores are eliminated. No partially dead
stores yet.
Example:
1: o.x = null;
2: if (cond) {
3: o.x = 1;
4: } else {
5: o.x = 2;
6: }
The store in line 1 is fully dead and will be removed. Note that
any deoptimization in "cond" will make the store only partially
dead and it won't be removed yet.
R=vegorov@google.com
Review URL: https://codereview.chromium.org//143263010
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@35909 260f80e4-7a28-3924-810f-c04153c831b5
Loads/stores with non-escaping arrays can be disambiguated from loads/store
with unknown identity.
This enables better load elimination for non-escaping arrays.
For example in the following code:
test() {
var a = new List(1);
var b = new List(1);
a[0] = 42;
b[0] = 43;
return a[0] + b[0];
}
we can now eliminate both loads a[0] and b[0] where before all stores to [0] were
considered to interfere with each other..
R=srdjan@google.com
Review URL: https://codereview.chromium.org//189543013
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@33523 260f80e4-7a28-3924-810f-c04153c831b5
The optimizer can now track side effects to array locations
at a constant index when eliminating array loads. Stores to
arrays with a constant index affect loads from arrays
at the same constant index _and_ loads from an unknown (non-constant)
index. Stores to an array with an unknown index affect all array loads.
For instance code like
var a = new List(2);
a[0] = 123;
a[1] = 456;
print(a[0] + a[1]);
we can now eliminate both loads from a[0] and a[1], where before
only the loads from a[1] was eliminated.
I changed the internal encoding of Alias to use BitField instead of
plain integers. This makes it a little easire to extend.
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org//145133009
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@32014 260f80e4-7a28-3924-810f-c04153c831b5
Since deserialization does not involve the normal object construction
procedure, any values written there won't be reflected in the guarded field
type. This results in incorrect optimized code because deoptimization of
dependent code objects in not triggered.
This CL adds tracking of field types and guarded list length when creating
objects via deserialization.
R=iposva@google.com
Review URL: https://codereview.chromium.org//50243004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@29741 260f80e4-7a28-3924-810f-c04153c831b5
By inserting the necessary checks for null inside the callee
at the AST level, the code generation of == operations can be
greatly simplified.
This is a performance-neutral change and a step for allowing
generic inlining of arbitrary == methods. So far we could only
inline them for a common set of types in the flow graph
optimizer.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//24203004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@28084 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 IsPowerOfTwo function is used together with ShiftForPowerOfTwo. Both function
do not work with zero. This caused the optimizing compiler to generate invalid code
for the expression
x ? 0 : 0
where it assumed that if one of the constants is a power-of-two, it can
be computed by (1 << n). We check for 0 in a number of places, but instead
I decided to fix Utils::IsPowerOfTwo itself and remove unnecessary checks
for the zero case.
TEST=tests/language/vm/if_conversion_vm_test.dart, runtime/vm/utils_test.cc
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//23604024
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27033 260f80e4-7a28-3924-810f-c04153c831b5
My previous approach was not enough, since methods can
be invoked via reflection before they are parsed/compiled.
This CL fixes the problem at hand, but I'd like a more general
approach to mark those methods. Maybe an annotation at the declaration
would be better.
I also refactored the test case as suggested in the previous code review.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//23458008
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27009 260f80e4-7a28-3924-810f-c04153c831b5
fschneider@google.com