Remove -fdata-section again from the Linux build configuration: It prevented
some optimizations in gcc and clang - fewer things were recognized as constants.
Add const to pointers/arrays in some places to help compilers with determining
what is a constant. A common pattern is strlen of a string literal const char*,
or an array of function pointers.
Tested with gcc 4.8.4 / clang 3.4 and improves code qualtiy + reduces binary size.
BUG=
R=iposva@google.com, rmacnak@google.com
Review URL: https://codereview.chromium.org/1462953002 .
fields in a thread (i.e fields that are not Dart VM related)
- Split the Thread structure to be a pure Dart per thread structure and add
a pointer to os_thread which points to the OSThread structure
- Change Schedule/UnSchedule to set the Dart Thread structure as the TLS of
the thread when it is inside the Dart world and reset the TLS back to the
OSThread strcuture when is exits the Dart World.
- Moved the stack_base and few stack size related functions to OSThread from Isolate
R=johnmccutchan@google.com, zra@google.com
Review URL: https://codereview.chromium.org/1439483003 .
This removes most of the compiler-related code from dart_precompiled:
x64 stripped binary size 13M -> 9.1M
ARM stripped binary size 12M -> 8.3M
The precompiled build defines the DART_PRECOMPILED macro. This
stubs out the public interface to the compiler/parser with empty
function bodies.
Use gcc options -ffunction-sections and --gc-sections to make the linker remove
unused functions/symbols.
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org/1459443002 .
Deferred deoptimization being moved ahead of entering field dependencies, attempt to use it for non-background-compilation as well. Previous failures not reproducible on Linux ia32 any longer.
BUG=
Review URL: https://codereview.chromium.org/1450973002 .
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 .
Instead of collecting closures functions in each class object, maintain one list per isolate. This is a step towards getting rid of top-level classes.
I'd appreciate if John could take a look at the service isolate and coverage related change.
I'd appreciate if Ryan could take a look at the precompilation related change.
When compiling all of corelib, the list of closures in the isolate is about 600 entries long. If this linear list should become a bottleneck, I'll deal with it later. (Sadly, some code relies on the fact that a closure can be identified with a list index, so making it a hash table instead of an array does not work.)
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org/1436243005 .
[1] has worse upper bound complexity than [2] but has lower
overhead. With [1] dart2js heaps would converge in ~10 iterations, but
with analyzer heaps would take ~10k iterations.
This reduces the time to analyze the final heap of the analyzer
analyzing dart2js from ~30 minutes to 26 seconds.
Increases peak memory usage by 21N bytes plus O(2N) words.
[1] "A Simple, Fast Dominance Algorithm." Keith D. Cooper, Timothy
J. Harvey, and Ken Kennedy.
[2] "A Fast Algorithm for Finding Dominators in a Flowgraph."
T. Lengauer and R. E. Tarjan.
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org/1449243002 .
- Defer deoptimization from optimizing compiler to code installation in mutator thread.
- Defer registration of field and leaf class dependency until code is installed in mutator thread.
- Cleanup.
BUG=
R=asiva@google.com
Review URL: https://codereview.chromium.org/1433243003 .
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 .
Ryan Macnak