The isolate was being passed around, even though only its current zone was used.
Pass that zone directly instead, giving two benefits:
1. helps prepare for the upcoming Isolate/Thread split, where "new(isolate)" must go, and
2. saves a pointer indirection at the allocation sites.
Review URL: https://codereview.chromium.org//855533002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@42935 260f80e4-7a28-3924-810f-c04153c831b5
In addition to tracking input and output ranges in the IC-stubs with a Smi fastpath (SmiAdd and SmiSub, currently) this CL also introduces two IC stubs that have no fast-path by still track ranges and update the range feedback.
We are able to distinguish between the following ranges (encoding of the lattice is shown in the parens):
- u-smi (0000)
- smi (0001)
- uint31 (0010)
- int32 (0011)
- uint32 (0100)
- int64 (1xxx) and (x1x1)
BUG=
R=fschneider@google.com, srdjan@google.com, zra@google.com
Review URL: https://codereview.chromium.org//735543003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@42370 260f80e4-7a28-3924-810f-c04153c831b5
There were two bugs in the code:
- we did not ensure proper outer environment on block entries after inlining;
- we did not correct the 'after' environment for eager deopt
There is one bug still with the infrastructure: our deoptimization stub does *not* support eager deoptimization to the after deoptimization point.
I am leaving it like this for now, because we don't actually ever perform such deoptimization (i.e. even though we diligently attach these environments we don't actually use them in the instruction that can deopt).
R=fschneider@google.com
BUG=
Review URL: https://codereview.chromium.org//784223006
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@42257 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
When computing the compile-type there should never be a value of
void type. The only value assignable to void is null, so the compiler
can use null-type as compile-type for such a value.
Before, the compiler would crash with an assertion-failure in checked
mode when running with the flag --no-eliminate-type-checks and assigning
the result of a static void function to a variable of some type.
This CL fixes the issue no matter how the flag is set. We could separately
consider removing this flag (it's default is true).
R=vegorov@google.com
Review URL: https://codereview.chromium.org//705063002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@41563 260f80e4-7a28-3924-810f-c04153c831b5
This change makes CTX available by not caching the current
context while in Dart code. Instead the current context
is held in a local variable (:saved_current_context_var) and
is passed as argument in CTX at calls.
This also simplifies a lot of code in the debugger: As a result,
Isolate::top_context is not needed anymore since the current context
can always be extracted from a Dart frame.
R=vegorov@google.com
Review URL: https://codereview.chromium.org//678763004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@41422 260f80e4-7a28-3924-810f-c04153c831b5
The motivation behind this change is that very large functions could
cause stack overflows in the (previously recursive) DiscoverBlocks
function. This commit introduces replaces recursive traversal by
iterative algorithms. Postorder traversal had to be removed from
DiscoverBlocks and is now done in a separate pass.
BUG=21109
R=vegorov@google.com
Review URL: https://codereview.chromium.org//617933003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@41016 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
fschneider@google.com