Insert Redefinition instructions to prohibit unsafe code motion. If we propagate
the receiver type downwards from a call to a unique selector, we must not hoist
instructions that were optimized using this type information across the call.
R=vegorov@google.com
Review URL: https://codereview.chromium.org/2498073004 .
This CL removes the use of STL map from freelist.cc by adding
MallocDirectChainedHashMap in hash_map.h and adding an iterator for
BaseDirectChainedHashMap there.
It also removes a use of STL map from hash_table.h that was dead code.
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org/2083103002 .
The optimizer now also deals with is-checks for num, double, _Smi in the
same way as it did for int before.
This CL eliminates many is-tests of constants that appear after inlining.
Also, make a better distinction between deoptimizing and non-deoptimizing
cases when replacing is-tests. e.g. InstanceOfInstr can't cause eager
deoptimization.
Also, improve tracing output when running e.g. --trace-inlining
Minor fix in raw_object.h.
BUG=
R=vegorov@google.com
Review URL: https://codereview.chromium.org/2074533002 .
Replace always_optimize_ and allow_recompilation_ with
FLAG_precompilation and !FLAG_precompilation.
They are equivalent and set only once according to the
--precompilation flag
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org/1657153002 .
Enable inlining of certain smi- and array-operations based on propagated
types and range analysis:
If bounds checks and class checks can not be eliminated, bail out of the
current optimization and retry without speculative inlining using the same
mechanism as we use for far jumps on MIPS.
Allow more speculative inlining attempts with up to n deopt ids black-listed.
For now set n=1 since precompilation time will be proportional to n.
BUG=
R=srdjan@google.com
Review URL: https://codereview.chromium.org/1423063005 .
Don't eagerly canonicalize the index boundary before getting
the constant value for comparison. Canonicalization may drop more
precise boundaries defined by already inserted constraints.
This enables eliminating the bounds-check in the following example:
test() {
var a = new Float64List(4);
for (var i = 0; i < 4; ++i) {
a[i] = 1.0;
}
return a;
}
Also, add pass of flow-graph canonicalization after load-optimization.
This enables more opportunities for ABCE in examples like:
o.f = new List(4);
o.f[0] = ...
BUG=
R=vegorov@google.com
Review URL: https://codereview.chromium.org/1434213005 .
This enables thread-safe logging (e.g., ISL_Print, which will soon be renamed to THR_Print), which is needed for concurrent
marking (DetachCode) and compilation.
Make finalization of GC marking tasks concurrent, now that it's thread-safe.
BUG=
R=iposva@google.com
Review URL: https://codereview.chromium.org//1314673008 .
Narrowing of ranges should only occur if the new range is actually
narrower than the old range. It can happen that a symbolic range
is worse than the already computed one. Ignore the new range in this
case.
BUG=dartbug.com/23693
R=vegorov@google.com
Review URL: https://codereview.chromium.org//1219623004.
Refactor all remaning cases where the current zone is used through new(Isolate*) and remove this interface.
Removing this interface is needed to move towards multiple threads per isolate, and also makes the caller more aware of the scope of the zone used, reducing the risk of use-after-free.
Make the current thread and the stack zone created around native/runtime entries directly available in their body, saving an indirection (and optimized away if unused).
R=iposva@google.com
Review URL: https://codereview.chromium.org//982873004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@44541 260f80e4-7a28-3924-810f-c04153c831b5
Even when range of the integer definition is unknown we can optimistically assign full int64-range to it even though tagged integer definition can contain instance of the Bigint. This is based on the following observation: we only use ranges when working with unboxed arithmetic in the optimized code, but the widest possible unboxed arithmetic is 64-bit (mint) one and corresponding unboxing operations will deoptimize if they get Bigint as an input. This makes it safe to assume that any integer definition fits into 64-bit range *once unboxed*.
Additional small fixes:
- Fix ranges assigned to loads from Int32/Uint32 arrays on 64-bit platform - it was overly conservative;
- Add UnboxUint32 range inference to ensure that range is not lost when it passes through box-unbox pair;
- When canonicalizing Binary/Unary Integer operations ensure that we unwrap UnboxUint32(Constant(C)) -> C.
BUG=
R=fschneider@google.com
Review URL: https://codereview.chromium.org//682993008
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@41640 260f80e4-7a28-3924-810f-c04153c831b5
replace it with a sequence of checks that guarantee
0 <= LowerBound(index) < UpperBound(index) < length
and hoist all of those checks out of the enclosing loop.
Upper/Lower bounds are symbolic arithmetic expressions with +, -, *
operations and are computed based on discovered simple induction variables.
Simple induction variable is a variable that follows the pattern v1 <- phi(v0, v1 + 1)
BUG=
R=fschneider@google.com
Review URL: https://codereview.chromium.org//619903002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@40969 260f80e4-7a28-3924-810f-c04153c831b5
Introduce base classes for binary and unary integer operations and move all shared logic (e.g. canonicalization) into these classes.
Start removing special cases dispatch from instructions patterns - it goes into Canonicalization pass.
Start removing duplication between instruction patterns where meaningful and possible.
Cleanup the notion of truncation in the operations: is_truncating implies !can_overflow, not the other way around.
BUG=
R=johnmccutchan@google.com, srdjan@google.com
Review URL: https://codereview.chromium.org//564843002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@40375 260f80e4-7a28-3924-810f-c04153c831b5
Switch to a fix-point based range analysis to improve its precision.
Dominator based algorithm was very imprecise for loop phis.
Use widening to ensure fast convergence and narrowing to improve precision.
Fixed compared to r39293:
Type propagation is more sophisticated now compared to the time
when range analysis was originally implemented and is able to derive Smi-ness
from more than just CheckSmi instruction (e.g. GuardFieldClass). This creates
situations when use's reaching type is Smi but definition itself is not a Smi
and thus will never have range assigned to it.
It is incorrect to treat ranges of such uses as unknown (_|_), because unknown
means "not yet computed". Instead we must use the widest possible approximation:
full smi range.
InferRange methods were rewritten to use a newly introduced GetRange helper
instead of accessing value()->definition()->range() directly.
As a side-effect we no longer need to insert artificial constraints after CheckSmi instructions.
R=fschneider@google.com
Review URL: https://codereview.chromium.org//477193002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@39327 260f80e4-7a28-3924-810f-c04153c831b5
Florian Schneider