I suspect that when the list of type preserving selectors was created the first/last setters either didn't exist or were just overlooked. Any dynamic List could have its inferred type changed by these operations.
Due to Dart2js's type representation this bug affects more than just dynamic lists. We track some simple values as part of the type system. So an operation that modifies a value can technically modify the type, as Dart2js represents it, even if the "real" type is preserved.
In the added test we would represent the list literal's type as "List(length: 2, elementType: Bool(true))". Notice the type states the elementType is specifically true, not just bool. Thus the first/last operations are modifying that type. But since we aren't registering this type change, SSA optimizes away the call/index and inlines the element itself.
Interestingly, this primarily manifested for bools due to a check in SSA:
https://github.com/dart-lang/sdk/blob/main/pkg/compiler/lib/src/ssa/optimize.dart#L475
In that code we are inlining constant-like expressions for the arguments of static invocations (such as the argument to a Expect.isTrue call). However, a few lines earlier you will see we only inline bool constants:
https://github.com/dart-lang/sdk/blob/main/pkg/compiler/lib/src/ssa/optimize.dart#L467
So when the list element type is anything other than a bool, this inlining does not trigger thus avoiding the bug.
Bug: https://github.com/dart-lang/sdk/issues/53944
Change-Id: I4e893903f335fc99b13cf526736c27bb066a4bad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334420
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Currently _narrowType for TypeInformation nodes has logic to process DartTypes. This logic is a simplified version of the logic in createFromStaticType. We can consolidate the two and just use createFromStaticType directly.
And since the static type is only ever used for this type narrowing (and its immutable) we can create the AbstractValue up front and store that instead of the DartType.
There was no difference in the emitted JS when tested on 2 large programs.
Change-Id: I432279684580edf64ff52254653bd26501d461b7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304160
Reviewed-by: Mayank Patke <fishythefish@google.com>
Type inference is not tracking the type of 'local' correctly through the switch statement into the inner return. The same code without the for loop does work correctly though.
Change-Id: I0b1b4741e4ff17c22dec3383defb412f5fff0836
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298980
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This CL replaces https://dart-review.googlesource.com/c/sdk/+/296900
The `List` constructor is removed in Dart 3.0.
Some of the `@patch` implementations were not removed.
This is *high priority*. It seems the left-over `@patch factory List` constructor did not cause any errors, instead it *added* a constructor to `List` that can be used in web compiled code. Even if `List` doesn't have such a constructor in the SDK code proper.
The VM and analyzer will say the invocation is an error, but dart2js happily compiles it and runs.
(It used to be that patches couldn't add public members, that security seems to have been removed.)
Also removes code which tries to detect "the unnamed List constructor",
which is no longer a thing, and a number of invocations of the constructor, where it's not clear that the test is aware that the constructor no longer exists, and is not marked as `@dart=2.x` with x < 12.
TEST=ci
Change-Id: I4ffaf3ae2c4e75ca06e7ba0bf19187b6376f3888
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297100
Reviewed-by: Brian Quinlan <bquinlan@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Inference runtime metrics on a large program:
-----Before-----
Duration - Mean: 182.303 Median: 174.500 Max: 292.0
Memory - Mean: 5857.426 Median: 5752.639 Max: 6167.91
-----After-----
Duration - Mean: 144.525 Median: 133.500 Max: 242.0
Memory - Mean: 5867.756 Median: 5727.506 Max: 6262.414
This shows ~20% improvement in runtime and virtually no change in memory usage. Previously we saw a memory regression due to this change. But thanks to improvements in the representation of TypeInformation nodes that memory regression no longer exists.
Code size for this program is also very similar before and after this change.
Before: 43258484 bytes JS
After: 43258444 bytes JS
Change-Id: I6512637f16d83f3127fd1c060bb770ae56405b88
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295460
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
- For parameters of closurized members make sure to mark the virtual parameter as closurized where appropriate. Closurized parameters are treated as dynamic and this needs to propagate to all the virtual target's overrides. Previously only the concrete target was getting marked as closurized.
- For mixins defining an abstract member, foo, implementations of foo (either directly on the mixin target or superclasses of it) should propagate their types to the abstract foo as they are effectively overriding it. Calls to foo within the body of the mixin can only target the abstract foo with a virtual call. So that virtual target needs to reflect the types of all its overrides.
Tests have been added that capture both of these cases. The values here reflect the non-linearized algorithm but prior to these fixes the linearized algorithms showed a diff for both tests. After these changes there is no diff.
This fixes all failures referenced in b/277876666.
Change-Id: Icaca99cb6902c54f481eebdbb65cbd7cf81aa2c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294960
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
This reverts commit 9aa00f6c75.
Reason for revert: breaks google3 (b/277876666)
Original change's description:
> [dart2js] Patch experimental inferrer (with linearized algorithm) into main inferrer.
>
> After this change for a large program we see:
> - 20% reduction in runtime (254s -> 202s)
> - 2% decrease in memory usage (7671.029MB -> 7524.901MB)
> - Code size decrease of <1% (214,788,150 bytes -> 214,757,445 bytes).
> - The k-limit of 6 refines imposed on the global inference algorithm is no longer hit for converging types. All but 15 types converge, down from 777 types that were hitting the k-limit before. This means we are likely generating better types/code for all 762 of those types.
> - More resilience to dynamic calls with lots of potential targets.
>
> Change-Id: I53d4ade51559f3366f076b6f2b485c5bdc50c6e8
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/271480
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
> Commit-Queue: Nate Biggs <natebiggs@google.com>
Change-Id: Ia6e038e8e077813e589a54d2242bd2820bd22036
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294741
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Emmanuel Pellereau <emmanuelp@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
After this change for a large program we see:
- 20% reduction in runtime (254s -> 202s)
- 2% decrease in memory usage (7671.029MB -> 7524.901MB)
- Code size decrease of <1% (214,788,150 bytes -> 214,757,445 bytes).
- The k-limit of 6 refines imposed on the global inference algorithm is no longer hit for converging types. All but 15 types converge, down from 777 types that were hitting the k-limit before. This means we are likely generating better types/code for all 762 of those types.
- More resilience to dynamic calls with lots of potential targets.
Change-Id: I53d4ade51559f3366f076b6f2b485c5bdc50c6e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/271480
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
We now attempt to evaluate
- final local variables with initializers
- final statics with initializers
- static or local function invocations if they just return an expression
by attempting to const-evaluate the initializer/returned expression.
Change-Id: I976863d950ba1609c5d8e6a21884ca56af0d2b4b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275145
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
Suppose we have code like
if (isDevMode) {
// do foo
} else {
// do bar
}
where isDevMode is const (or can be evaluated as const). In particular,
isDevMode can be controlled by compile-time options, like
bool.fromEnvironment.
We currently eliminate the dead branch during SSA, but that means we do
the work of compiling dead code in the previous phases. Instead, we can
recognize that the condition is const (or effectively const) and
eliminate the dead AST subtree directly.
Change-Id: Ia91da5ebc7fa496a1b963308c6e02d572cab936e
Bug: b/254543452
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/270281
Reviewed-by: Sigmund Cherem <sigmund@google.com>
These are scattered changes to get to type inferrence.
- Add some impact tracking for used record types
- Add RecordTypeInformation and FieldInRecordTypeInformation
- Add a simple test to show inference is currently very conservative.
Change-Id: Icb81033b11588c1bddd01c8c5fcf69950fdb77e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275161
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
The type bounds in each case statement can diverge when a break is hit in a conditional control flow block. Previously the switch statement was just merging the end state after visiting each case block. Instead we need to merge all possible termination states for each case.
This is trivial when the switch only contains breaks. The termination states are just those when we reach each break (or the end of the switch if there's a default).
When there are switch-continue statements we must reconcile the states that flow into each targeted switch before reconciling the types of those targeted switches themselves. We achieve that by making two passes over the cases, the first to gather the continue states and the second to update the switches affected by those states. Similar to before this is done repeatedly until a fixed point is reached.
Fixed: 46770
Change-Id: I5795748a4591e6a1dc283f2a54129e09a20d13d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/250200
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Late fields start out holding a sentinel value and after they are initialized or assigned, never hold a sentinel value again.
This CL implements some removal of checks and loads based on this monotonic behaviour.
On two large Dart Angular apps, this reduces the number of late-instance-field checks by ~25%.
One app is 0.44% smaller, the other is 0.98% smaller.
The optimization_test.dart no longer forces `--disable-inlining` because that prevents the inlining that exposes the optimization opportunities.
Most tests already use `@pragma('dart2js:noInline')` to prevent inlining where relevant.
Change-Id: I2327a96e69191313ed6c07eabe94aa2962fb2648
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246881
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
A bug in global inference made the analysis accidentally carry over
the state of a nested condition in a subexpression and conclude
that it was part of the state of the outer condition.
This was due to the fact that we didn't clear the state when
popping out of the context and reentering the conition state.
Fixes https://github.com/dart-lang/sdk/issues/48571
Change-Id: I4e8294bb1a05bb3b910b6aec374357d75acb67cb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240321
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Global type inference incorrectly handles conditions nested within
subexpressions and accidentally carries information from those
in the context of outer conditions.
Change-Id: I99e0af3da65590acb9429771b318b7da8f3b7f14
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240320
Reviewed-by: Stephen Adams <sra@google.com>
Changes in type hierarchy will have JavaScriptObject as the new
parent class of interop and native types instead. Also modifies
js_interop_constructor_name tests to reflect addition of static
interop.
Change-Id: I74957ca89aea1726a01e0677548fbb3c5c981323
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215949
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
We use an extension getter instead of an instance getter because
it doesn't conflict with any potential existing or future enums
which want an element named `name`.
Keeping the namespace for enum elements open is a priority.
We currently only reserve `index` and `values`.
BUG: https://github.com/dart-lang/language/issues/1511
Fixes language issue #1511, which is a long-standing request,
and should replace a number of alternative implementations
which are based on parsing the `toString()`.
This version has two fields on the shared superclass, the index
and private name, and has a separate `toString` for each `enum` class
which hard-codes that enum's class name.
An earlier version had both `"name"` and `"ClassName.name"` as fields
to be able to reuse the same `toString` method on all enum classes,
but that cost too much for JS compiled code.
Even having just `ClassName.` as a field and then combining inside
`toString` requires more code to create the enum instances.
Instead this version hardcodes the `ClassName.` string once
in the `toString` method, which means each enum class has its own
toString (which can *potentially* be tree-shaken then.)
This still tree-shakes slightly worse than the previous implementation
where every enum class had its own `index` and `_name` fields
independent of each other, which could then be tree-shaken independently.
However, the `index` was already made an interface member with the
addition of the `Enum` interface, so code which accesses `.index`
on something of the `Enum` supertype could prevent tree-shaking of
all enum classes' `index` fields.
Likewise any general access to the "name" of an enum would necessarily
do the same for the name.
This CL makes up for some of that by sharing more implementation
between enum classes.
DartVM AOT CodeSize impact: ~0.15% regression on gallery (little less on big g3 app)
TEST= New tests added to enum_test.dart
Change-Id: Id25334e6c987f470f558de3c141d0e3ff542b020
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210480
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
In the inferrer code like `local == null` would use the type information
for the operands to determine whether the call was `o == null` or
`null == o`. This had the side effect that if the left operand was a
local variable known to have value `null` the case would be treated as
`null == o` and the local would not be promoted to non-null on the false
branch.
Change-Id: I5fa08f8c891578f4c8e337e6cf5882fc2383063f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/189210
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
JSDouble was really "double *excluding integral values*".
This was confusing, with JSDouble sometimes used assuming it was all doubles.
Rename JSDouble to JSNumNotInt to avoid future errors like #44818
Change-Id: I96bf33d5531b94aaf33b582e584702f47ed50395
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/183201
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Nate Biggs