The type Map<T, Foo<Set<T>>> contains one type variable referenced twice,
so there are two inputs into the HTypeInfoExpression instruction.
If Foo is a typedef, T can be reused, e.g.
typedef E Foo<E>(E a, E b);
As the typedef is expanded (to Function(Set<T>, Set<T>) => Set<T>) it
should not consume additional types from the to-level input. We
prevent this by capturing the types and using the captured type
expressions inside the typedef expansion.
TODO: We should make the type subexpression Foo<...> be a second
HTypeInfoExpression, with Set<T> as its input (a third
HTypeInfoExpression). This would share all the Set<T> subexpressions
instead of duplicating them. This would require HTypeInfoExpression
inputs to correspond to type variables AND typedefs.
BUG= https://github.com/dart-lang/sdk/issues/28749R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2812393003 .
This is a step towards using data object rather than Compiler and
JavaScriptBackend in codegen. This is needed to support a shift in
element models between resolution and codegen.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2811593006 .
This is a step towared computing the closed world purely from kernel based elements.
The added test runs the resolution enqueuer on a kernel based world.
Some methods and classes are mocked and no closed world object is computed, yet.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2810633003 .
This is a substructure of FunctionType and FunctionSignature which
doesn't contain type information. This allows us to let FunctionEntity
have a ParameterStructure (which makes sense for both K and J elements)
but not require FunctionEntity to have a type (which K elements have
but J elements might not).
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2809603002 .
This is a step towards using data objects instead of directly accessing
JavaScriptBackend and Compiler. This is needed to support an element model
switch between resolution and codegen.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2808683003 .
This is a step towards using data object rather than Compiler and
JavaScriptBackend in codegen. This is needed to support a shift in
element models between resolution and codegen.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2813603002 .
There is one case where compilation is much slower (corelib/regexp/pcre_test).
Reverting while investigating.
The test has a 6.6K-line main() with straight-line code.
Before:
SSA optimizer took 78552msec
SSA optimizer > SsaInstructionSimplifier took 21434msec
SSA optimizer > SsaTypeconversionInserter took 12msec
SSA optimizer > SsaRedundantPhiEliminator took 1msec
SSA optimizer > SsaDeadPhiEliminator took 0msec
SSA optimizer > type propagator took 15639msec
SSA optimizer > SsaCheckInserter took 18msec
SSA optimizer > SsaDeadCodeEliminator took 35806msec
SSA optimizer > SsaGlobalValueNumberer took 564msec
SSA optimizer > SsaCodeMotion took 1msec
SSA optimizer > SsaLoadElimination took 360msec
SSA optimizer > SSA value range builder took 4700msec
SSA optimizer > SsaSimplifyInterceptors took 2msec
After:
SSA optimizer took 156299msec
SSA optimizer > SsaInstructionSimplifier took 18700msec
SSA optimizer > SsaTypeconversionInserter took 7msec
SSA optimizer > SsaRedundantPhiEliminator took 1msec
SSA optimizer > SsaDeadPhiEliminator took 0msec
SSA optimizer > type propagator took 52763msec
SSA optimizer > SsaCheckInserter took 26msec
SSA optimizer > SsaDeadCodeEliminator took 31066msec
SSA optimizer > SsaGlobalValueNumberer took 596msec
SSA optimizer > SsaCodeMotion took 2msec
SSA optimizer > SsaLoadElimination took 368msec
SSA optimizer > SSA value range builder took 52752msec
SSA optimizer > SsaSimplifyInterceptors took 2msec
BUG=
Review-Url: https://codereview.chromium.org/2804193002 .
Consider:
value ??= "";
We fail to infer in SSA type progagation that value is non-null.
At CFG level this looks like
if (value == null) {
value = "";
} else {
// There is always an empty else-block.
}
value1 = phi("", value);
Previously we considered the phi use of 'value' to be outside the
region dominated by the condition 'value != null', leaving nowhere to
attach the type refinement. Now we consider it inside the region,
allowing:
if (value == null) {
value = "";
} else {
value1 = HTypeKnown(not-null, value);
}
value2 = phi("", value1);
Type propagation now determines value2 is non-null.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2755353003 .
The old code killed bindings by storing `null`. It is possible to
construct straight-line code with takes time and space O(N^2) to do
load elimination, since all the useless nulled-out bindings are
re-walked on every killAffectedBy call.
Luckily most of our generated code has some joins which cause the
intersection to be computed which deletes the unused bindings.
BUG=
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2770563002 .
Stephen Adams