Also extract more extract more methods from ClosedWorldImpl into
ClosedWorldBase.
This is a step towards creating a closed world object from kernel based
elements. This CL adds the first mock of that object.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2826673002 .
This is a step towards passing data object directly instead of accessing
data on JavaScriptBackend. This is needed to support an element switch
between resolution and codegen.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2824823004 .
This is a step towards passing data object directly instead of accessing
data on JavaScriptBackend. This is needed to support an element switch
between resolution and codegen.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2820143004 .
This is a step towards passing data object directly instead of accessing
data on JavaScriptBackend. This is needed to support an element switch
between resolution and codegen.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2823003003 .
This is a step towards passing data object directly instead of accessing
data on JavaScriptBackend. This is needed to support an element switch
between resolution and codegen.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2810223002 .
This is a step towards passing data object directly instead of accessing
data on JavaScriptBackend. This is needed to support an element switch
between resolution and codegen.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2815513007 .
This is a step towards passing data object directly instead of accessing
data on JavaScriptBackend. This is needed to support an element switch
between resolution and codegen.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2818463002 .
This is a step towards passing data object directly instead of accessing
data on JavaScriptBackend. This is needed to support an element switch
between resolution and codegen.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2810183002 .
- and Compiler from type_test_registry.
The CodeEmitterTask was removed from the TypeRepresentationGenerator to
break a dependency cycle between the two. An Emitter is now provided as
an argument to TypeRepresentationGenerator methods instead.
This is a step towards passing data object to the codegen/emitter
instead of pulling data directly from Compiler/JavaScriptBackend. This
is needed to support an element model switch between codegen and
resolution.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2809203003 .
1. Simplify HPhi nodes that merge refinements of the same value.
2. Replace the condition of HIf with a constant when the HIf does nothing (no controlled statements or phis).
Together with existing optimizations, this can optimize `s?.toString()` to `s` when `s` is known to be a nullable String.
BUG=
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2823543002 .
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 .
Johnni Winther