In the case of ssa, I also removed references to AST nodes in ssa nodes that were unused, so now only the builder imports the AST.
I also got rid of unused imports from everywhere else in the code.
R=sra@google.com
Review URL: https://codereview.chromium.org/1762723002 .
NodeList mixes in IterableMixin<Node>. This makes the object bigger,
costing ~3% extra size for the Dart AST. (10MB out of 350MB)
One idea would be to revert this change and make all the for-in sites use
the .nodes member.
Link<T> now implements Iterable<T>, with missing methods added.
IterableMixin could not be used since Link has a const constructor.
I would like to see Link<T> replaced with fixed length lists or
unmodifiable lists.
A couple of other classes were modified to return an Iterable.
R=sigmund@google.com
Review URL: https://codereview.chromium.org/1783053005 .
There is no need to set the runtime type on an object whose
type arguments are all 'dynamic'.
Also use a more precise precondition for eliminating a
ReadTypeVariable access.
BUG=
R=kmillikin@google.com
Review URL: https://codereview.chromium.org/1784263002 .
- No longer attribute queries to type inference. Queries are attributed to client.
- Remove vestigial CPA code
- Don't compare target sets for additions and deletions if they are
the same (most of the time we revisit the dynamic call site due to
a change in a returned result).
R=sigmund@google.com
Review URL: https://codereview.chromium.org/1777393003 .
Removing the `_assignments` and `users` collections from TypeInformation
nodes causes interior nodes (e.g. Phi, Narrow) to become unreachable and
available for GC. This seems to trim 1%-5% off the final heap of an SSA
compile.
R=sigmund@google.com
Review URL: https://codereview.chromium.org/1776533002 .
This adds a source mapping to variable declarations in the beginning of a JS function, that points to the start of the corresponding Dart method:
foo: function() {
var a, b;
^
maps to
foo() {
^
R=sigmund@google.com
Review URL: https://codereview.chromium.org/1772703002 .
Previously, the "receiver" of an InvokeMethod would be either be the
"Dart receiver" or an interceptor, depending on the calling convention.
Likewise, the argument list was possibly prefixed by the Dart receiver.
Now, the receiver is always the Dart receiver, and the arguments are
the Dart arguments and the interceptor is in a field specific for the
interceptor.
The old way was very inconvenient in the CPS, it has led to several
bugs already, and it's just unintuitive that "receiver" can mean two
very different things.
FunctionDefinition no longer has a thisParameter, but
instead a receiverParameter and an interceptorParameter. These are
named to correspond exactly with the names used in InvokeMethod.
The concept of 'this' has been removed from the CPS IR to hopefully
avoid confusion between 'Dart this' and 'JS this'. There is now only
receiver and interceptor, and which one corresponds to the JS 'this'
is irrelevant.
The Tree IR has not changed. The Tree IR builder is thus responsible
for translating the calling convention into the JS receiver and
argument list. The Tree needs to know the order in which the operands
are evaluated, so it makes sense to keep this form in the Tree.
R=sra@google.com
Review URL: https://codereview.chromium.org/1761903002 .
Primitives now getter for its side effects, as a bitmask.
This avoids a lot of code duplication between GVN, BoundsChecker, and
LoopSideEffects.
There are more flags than those in the SideEffects class (which is used
by the SSA backend, foreign code annotations, and type inference).
We are going to need these extra flags in general, but I want to use
them in the CPS first to see how they work out.
Upcoming changes which are "loose ends" in this CL to keep it manageable:
- Simplify GvnVectorBuilder using dependency flags.
- Stop the overuse of isSafeForElimination.
- Add the extra flags to the rest of the compiler.
BUG=
R=sigmund@google.com
Review URL: https://codereview.chromium.org/1645053002 .
Harry Terkelsen