This adds four helpers:
- InteriorExpression: remove, insertAbove, and insertBelow.
- Primitive: destroy.
As discussed elsewhere, using such helpers is a double-edged sword.
They make the code easier to read and write, but it's easy to end up
with helpers that look like they work for a particular purpose, but
actually don't because of slight variations in different use-cases.
These methods have a couple of pitfalls, like forgetting to unlink
references after a call to `remove`, or accidentally using the body
of an orphaned node. But these are generally caught quickly in
checked-mode so, it seems like it will be worth it.
BUG=
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//1375513002 .
Neither of these optimizations can "obviously" be placed before any of
the others without missing out on an optimization:
Constifying an interceptor makes it LICM'able because its dependency on
the input disappears. This suggests we should constify before LICM.
Interceptors in disjoint scopes might become sharable after LICM.
This suggests we LICM before sharing.
Constifying an interceptor can prevent sharing, because we "forget"
which input it came from. This suggests we share before constifying.
The last point could also be resolved by performing a stronger analysis
to determine which interceptors in scope are a valid substitute for a
given interceptor. But having everything in one pass isn't too bad.
BUG=
R=sra@google.com
Review URL: https://codereview.chromium.org//1364703004 .
Because of this bug, the tree IR had a tendency to put throw
statements at the bottom of a method, even if it meant inserting
an explicit negation in a branch.
BUG=
R=sra@google.com
Review URL: https://codereview.chromium.org//1368963002 .
Passing the -v flag to dart2js now prints the time spent in individual
optimization passes.
It should also be easier to throw in ad-hoc timing of specific
procedures for some quick-and-dirty timing measurements.
BUG=
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org//1362953002 .
This bug was only happening for the --fast-startup.
For most browsers we simply change the '__proto__' and the order wouldn't be important. However, for the other browsers we have to do it in order.
R=sigmund@google.com
Review URL: https://codereview.chromium.org//1347423003 .
Setting receiverIsNotNull, objectIsNotNull in the analysis pass
simplifies the transformation pass since predicates like
'isSafeForElimination' depend on them.
This would prevent constant folding of array lengths since
GetLength was not marked as safe for elimination at the
time it was considered for constant folding.
BUG=
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//1348233002 .
Still under a 'flag'.
Enable with:
DART_VM_OPTIONS=-Dunreachable-throw=true <compile>
These tests fail with an [empty] input to createRuntimeType.
DART_VM_OPTIONS=-Dunreachable-throw=true tools/test.py -mrelease -cdart2js -rd8 dart2js_extra/deferred/deferred_mirrors1_test
DART_VM_OPTIONS=-Dunreachable-throw=true tools/test.py -mrelease -cdart2js -rd8 dart2js_extra/mirrors_used_warning2_test
R=sigmund@google.com
Review URL: https://codereview.chromium.org//1355873003 .
When I was experimenting with inlining, I triggered a violation of the Tree
integrity checker after variable merging, because variable uses in the
typeInformation were not rewritten.
R=asgerf@google.com
BUG=
Review URL: https://codereview.chromium.org//1356903002 .
* Type annotations were not correct anymore, since we refactored type
propagation.
* Continuations were not decorated. This meant that they weren't marked
with '**' when they caused an integrity violation.
* There was a bug in the arity of calls to _currentIsolate that manifested
when trying to build the argument list string.
* Formatting needed some small cleanups.
R=karlklose@google.com
BUG=
Review URL: https://codereview.chromium.org//1345983007 .
Type inference uses the closure tracer to decide whether it has sufficient global
information to compute an actual type on a closure. If tracing fails, it will
abandon type inference for that closure. However, we no longer fail tracing just
because a closure flows into Function.apply, as this still means that we have
seen all use sites. Unfortunately, type inference does not understand that
Function.apply is actually a call site (and we lack other information to make
this knowledge worthwhile). So it concludes that the closure is never called.
With this fix, it now correctly abandons inference again.
The second issue was that we only take default values into account when looking
at a call site (so that we only use them if they are actually used). This can be
decided statically unless we loose track or there is a call to Function.apply.
I have added an extra edge to the use-graph so that there now always is a use
edge from a default to the parameter. While this is conservative, it will only
affect tracing and thus only the types of traced entities that are used as
default should be impacted.
BUG= http://dartbug.com/24297R=sigmund@google.com, sra@google.com
Review URL: https://codereview.chromium.org//1355563002 .
Asger Feldthaus