Before this CL we would miss some dependencies when recording
dependencies because we cache certain calculations that upon calculation
can mark things as needed.
Change-Id: If9ff872021b0fb77cbcc787112bb91f3ade71243
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118281
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Before this CL we would miss some dependencies when recording
dependencies because we don't finalize exports of dill libraries we have
already finalized.
This was a previous speed-optimization that worked fine before recording
dependencies, but - as outlines above - doesn't work together with
recording dependencies.
Change-Id: I3d9abe949e2b614e9bcd03711e7b92f586373ec5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118043
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Fixes the changes to assembly snapshot writer in SIMARM_X64 mode. This unfortunately can't be tested until the ELF loader is available.
Take 2 is in patchset 1.
Change-Id: Ib8b067dd4f09dcba3b142705e9cb4dfbf4e3eb53
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/117726
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This refactoring achieves the following:
- Collect the integer operation semantics into one place instead of
having it sprinkled all over the constant evaluator with many
"if (targetingJavaScript)" tests.
- Avoid emitting the internal JavaScriptIntConstant node, which is
serialized as normal DoubleConstant nodes, thus achieving parity
between direct consumers and consumers seeing output that has been
serialized.
- Implement the JavaScript semantics for unsigned right shift.
- Fix truncating divide with a result outside int64 range incorrectly
clamping the result for JS targets.
- Fix positive hex constants >= 2^63 through int.fromEnvironment
producing negative values in dart2js.
- Clarify in Kernel documentation how numeric constants are represented
on VM vs JS targets.
Change-Id: If30bb2c2c77c54eff120b611b059c2ec726c99a0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/116525
Reviewed-by: Mayank Patke <fishythefish@google.com>
We've long had the ability to load a combined dill file both in the dart
code and in the VM.
Largely this has been untested though - this CL adds a test.
Change-Id: I7cf03911d716999c2bdb407b256a064d84a385ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/117152
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Change Judgment classes that are 1-to-1 extensions of kernel nodes into
*Impl classes that do not implement *Judgment.
Change-Id: Ia49b131cfb30e7e5c0d5f26a8a43e6dd6d05d2ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/116062
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Removes StatementJudgment, ExpressionJudgment, and InitializerJudgment
classes that are identical to existing nodes.
Change-Id: If67c1972387bb158bfe775cdf091cae4eadd47c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/116061
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
This CL gives the option to load classes lazily (on by default),
meaning that fields, procedures, constructors and redirecting
factory constructors of classes are not initially read,
but instead read when (or if) needed.
The idea being that many classes aren’t needed, and that
spending time on reading them is thus just a waste of time.
This is especially true in modular compilation where a lot
of modules needs to be given as input as the compilation at
hand might technically rely on it, but in practice only very
few of the classes are actually needed (or very few classes
actually need their members).
The below numbers are comparing a VM without this change and without
the lazy class hierarchy member lists change with
b31566b297 (the base change for those
two changes).
For running a simple hello-world script, on my machine 500 times
and doing statistics on it I can measure the following differences:
With verbose, from kernel_service startup to compile complete:
Difference at 95.0% confidence
-17.8 +/- 0.555817
-24.3455% +/- 0.760206%
(Student's t, pooled s = 4.48379)
With verbose, total runtime measure by `time`
Difference at 95.0% confidence
-19.346 +/- 0.905217
-12.0333% +/- 0.563051%
(Student's t, pooled s = 7.30242)
Without verbose, total runtime measure by `time`
Difference at 95.0% confidence
-17.862 +/- 0.842905
-12.0635% +/- 0.569276%
(Student's t, pooled s = 6.79974)
For running a number of modular compilations I’ve recorded an
improvement in actual runtime in the order of 20-37% depending
on the circumstance. In a real build system, though, the
difference seems to be more in the order of around 5%.
Change-Id: Id329bcf2b01d12c12d7a49f2b8abacd9c2447f05
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115703
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This situation would produce an error referring to the erroneous type
as a return type instead of a paremeter/field type.
Change-Id: Ida72b0b85b448e3a05cadf38511e7e32d19986f1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115702
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Johnni Winther