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