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
Instead of having special handling for closure calls, pass
the number of input operands down so that the correct lazy
deoptimization environment is generated at calls.
There is no functional change here - this is to simplify
having calls with pushed arguments and input operands
(like closure calls).
Runtime calls still do not have a correct lazy deoptimization environment
the environment should only be used for creating stack traces
from optimized code.
Fix a bug with --trace-deoptimization-verbose printing: We
cannot call ToCString on objects when the slots have not
been filled in yet. (e.g. Closures)
R=vegorov@google.com
Review URL: https://codereview.chromium.org//575443002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@40306 260f80e4-7a28-3924-810f-c04153c831b5
The parallel move resolve has to block reserved registers like
TMP, TMP2, PP, CTX so that they are not used as scratch registers.
Use allocated scratch register instead of IP because IP may be
used for large stack slot offsets.
This CL also generalizes stack-slot locations to address
stack lots relative to FP or SP.
R=zra@google.com
Review URL: https://codereview.chromium.org//539073002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@39905 260f80e4-7a28-3924-810f-c04153c831b5
This change generate inline code for context allocation and makes
the stores to initialize the parent pointer and the context variables
explicit in the optimized flow graph. This allows dead store elimination
to eliminate those stores.
Before, we only had inlined context allocation for ia32.
Furthermore:
* Added an assertion that the exit label of slow-path code
is bound when emitting deferred code. This used to cause random crashes
if forgotten.
* Fixed a bug in allocation stats on ARM.
BUG=dartbug.com/17238
R=srdjan@google.com
Review URL: https://codereview.chromium.org//346823003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@39202 260f80e4-7a28-3924-810f-c04153c831b5
On these architectures it's preferable to load Scavenger address into the register and then access top/end fields through this register instead of loading addresses of those fields as immediates --- which takes either two instructions or a memory load through a pool pointer.
Cleanup boxing slow-paths in the optimizing compiler. We had tons of duplicated code that was essentially doing the same thing.
BUG=
R=johnmccutchan@google.com, regis@google.com
Review URL: https://codereview.chromium.org//410333003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@38539 260f80e4-7a28-3924-810f-c04153c831b5
1) Iterate from first_free_register to last_free_register to ensure we're not using protected registers.
2) Break when finding an ok register.
2) fixes allocating PC on ARM by itself, but we could need 1) for another architecture.
The reason this has not been exposed yet, is because we call this method for a memory <-> memory
swap, which almost never happens on ARM.
R=vegorov@google.com
Review URL: https://codereview.chromium.org//337503003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@37304 260f80e4-7a28-3924-810f-c04153c831b5
The bit has_finally was only used to skip the checking of the stack height
at return statements: There was an unused value floating on top of the
expression stack in unoptimized code if the finally block preceded a normal
return statement. Normallyi, that does not cause harm. Optimized code is not
affected since it has a fixed stack size for expression evaluation.
This CL fixes the stack height for functions with try-finally by introducing
a temporary local where the return value is saved before an inlined
finally-block.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//149603003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@32157 260f80e4-7a28-3924-810f-c04153c831b5
When untagged values flow into a exception-throwing instruction
they need to be converted eagerly. Catch block entries assume all
values are tagged at the entry.
I changed the generation of moves at throwing
instructions in try-catch: Instead of manuallu emitting moves,
construct a parallel move and use the resolver to emit the native code.
This eliminates a lot of duplicated code from all platforms.
It will also allow to re-use stack space that is currently allocated
separately for each individual try-catch in a function.
I added a few more unrelated minor changes in various parts of the VM
* Simpilify guard code generation
* Resolve refactoring TODO in deoptimization
* Improve names
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org//125103002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@31536 260f80e4-7a28-3924-810f-c04153c831b5
This CL has no change in functionality and is purely clean up and
refactoring. Instead of manually generating the moves at throwing
instructions in try-catch, construct a parallel move and use the resolver
to emit the native code. This eliminates a lot of duplicated code
from all platforms.
It will also allow to re-use stack space that is currently allocated
separately for each individual try-catch in a function.
I added a few more unrelated minor changes in various parts of the VM
* Simpilify guard code generation
* Resolve refactoring TODO in deoptimization
* Improve names
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org//119213002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@31326 260f80e4-7a28-3924-810f-c04153c831b5
This is another refactoring step. It turn all comparisons
to be generated after the same pattern and removes duplicated
code from each of the different comparisons (smi, mint, double, etc.)
A comparison as an expression now follows the same patterns as a comparison
inside a branch. It just adds a common epilogue to materialize the boolean
result.
In another CL this common epilogue will be generated by reusing the IfThenElse
IL instruction.
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//64483002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@30243 260f80e4-7a28-3924-810f-c04153c831b5
This CL is the first step in refactoring the way branches and comparisons
are generated.
1. Move helper functions from flow_graph_compiler_xyz.cc to
intermediate_language_xyz.cc.
2. Remove IL class ControlInstruction. It was only implemented by BranchInstr.
All functions provided are moved to BranchInstr.
3. When generating branch code for comparisons, pass the successor labels explicitly
instead of getting them from the branch. This will allow us to provide different labels
when materialize a bool value of a comparison.
4. Move some common code for IfThenElseInstr from the platform-specific files
into intermediate_language.cc and simplify it.
The goal is to enable if-conversion of arbitrary comparisons. Right now,
the code for == is hard-coded in IfThenElseInstr (and duplicated, too). This
means that e.g. "a < b ? 0 : 1" cannot be optimized.
As a result, IfThenElseInstr can be used to materialize the boolean value of
a comparison. This way the complication of having ComparisonInstr both as a
normal instruction and as wrapped inside a BranchInstr can be simplified.
Comparisons would no longer appear as plain instructions in the IL, but only
wrapped inside either a Branch or an IfThenElse(true, false).
R=zra@google.com
Review URL: https://codereview.chromium.org//62133002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@30042 260f80e4-7a28-3924-810f-c04153c831b5
srdjan@google.com