When we perform constant evaluation in the CFE, the FFI transform
runs after constant evaluation. Thus, it needs to generate pragmas by
directly producing a constant, rather than calling the pragma
constructor.
Change-Id: I3659fe77fde95e7797550900ff896748996758ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/111734
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Normally, TFA runs after constant evaluation and it expects @pragma
annotations in the evaluated form. In unit tests TFA runs after
front-end and it was expecting @pragma annotations in the expression
form. With constants-update-2018 front-end starts evaluating constants,
so TFA unit tests should switch from ExpressionPragmaAnnotationParser
to ConstantPragmaAnnotationParser.
This CL does not update test expectations as flag is not flipped yet.
Test expectations should be updated when flipping a flag using
tools/test.py -m release --vm-options -DupdateExpectations=true pkg/vm
Change-Id: I94ee2de9f70328ce3ed3ffd9902a92eeb26d3a29
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108840
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Samir Jindel <sjindel@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
In general case, TFA approximates results of recursive calls using static
types.
However, if result type of a function does not depend on the flow inside its
body, it cannot change and it can be used in case of recursive calls
instead of a static type.
This improves micro-benchmark from #37455:
Before: 0m11.506s
After: 0m7.324s
Issue: https://github.com/dart-lang/sdk/issues/37455
Change-Id: I967d7add906c8dbd59dbbea1b993e1b4e1733514
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108500
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Move generation of Function objects for native trampolines to the Precompiler, so they can be generated during AOT and tree-shaken if possible.
Issue dartbug.com/35765
Change-Id: I0e69b7e0b22db73e3a40f2fe445660e57ddb6fa9
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-bare-linux-release-simarm64-try, vm-kernel-precomp-bare-linux-release-x64-try, vm-kernel-precomp-linux-debug-x64-try, vm-dartkb-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107407
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Pkg/vm tests were adjusted after constant evaluation was enabled in the front-end.
As constant evaluation was reverted (4b7d256a06),
we also need to revert corresponding changes in pkg/vm unit tests.
Revert "[vm/bytecode] Update expectations for bytecode generator unit test"
This reverts commit 734c50cbf2.
Revert "[vm/aot/tfa] Update TFA tests after front-end starts evaluating constants"
This reverts commit 25cb45c02f.
Change-Id: I2fcc30571bec2dd904925724ddb7105567c7ecda
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/99782
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Usually TFA takes kernel AST with all constants evaluated.
However, in order to avoid calling constant evaluator pass in TFA unit tests
there is a special implementation of pragma annotation parser (for testing)
which accepts annotations which are not ConstantExpressions.
After CFE starts evaluating all constants (constant-update-2018 was enabled in
e9ca6a5335), TFA unit tests need be
switched to use ConstantPragmaAnnotationParser.
Also, empty environment defines are passed to CFE to avoid unevaluated constants
and unit test expectations are updated.
Closes https://github.com/dart-lang/sdk/issues/36602
Change-Id: I2e7b0647e065cca129449b4531c6278c1d98061d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/99269
Reviewed-by: Samir Jindel <sjindel@google.com>
This change adds option --protobuf-tree-shaker to enable protobuf tree
shaker transformation in gen_kernel and Fuchsia kernel compiler.
Protobuf tree shaker requires closed world and only works with --aot
and --tfa.
Change-Id: I9fcc7934624f2d11f9b04215f1a81367f8ec82e6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98781
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Sigurd Meldgaard <sigurdm@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
The .getStaticType results for NullLiteral and NullConstant are inconsistent. The former returns `const BottomType()` and the latter return `TypeEnvironment.nullType`.
To avoid this inconsistency and since `const BottomType()` is really the "unreachable" type, used for instance of for the type of a throw expression, the implementation is changed to consistently use the .nullType.
For this to work, getStaticTypeAsInstanceOf (and the equivalent dart2js implementation), and the `Type.fromStaticType` constructor in the VM type flow analysis have to special case the .nullType.
Change-Id: If6b806d4a39ef7b906275c43fa2089b9d140523b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98563
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
To properly recognize control-flow constructs in sets, the constant
evaluator needs to get un-desugared set literals. This commit skips the
desugaring of const set literals if the constant evaluator is enabled
and adds a similar desugaring in the constant evaluator.
Doing the desugaring in the constant evaluator (which can be called
independently of Fasta) necessitates that dart:collection is indexed
in CoreTypes. We can remove this indexing again when the VM gains
native support for set constants.
Change-Id: Ibddafdcb182e4471012801745b51b529805b7b9f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98008
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
This achieves consistency with similar getters in the API.
This is technically a breaking change, since it changes a published
part of the Kernel API. Since the constants API is relatively new and
so far only used internally in the AOT compiler, the change is
expected to be unproblematic.
Closes https://github.com/dart-lang/sdk/issues/35696
Change-Id: I3ca30922580d226ccbdb6f77496983c21ef2102b
Reviewed-on: https://dart-review.googlesource.com/c/90220
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Validating the class hierarchy requires subtype tests. Previously,
Fasta has worked around this by computing the hierarchy twice, as
well as visiting the hierarchy several times. In order to improve
performance of modular compilation, we're working on changing this.
To enable creating a TypeEnvironment without a hierarchy, we're
removing the field from the API.
Change-Id: I7c9f88d5c6495aaa8223eaeff7d2dfd5669e9e95
Reviewed-on: https://dart-review.googlesource.com/c/88823
Reviewed-by: Alexander Markov <alexmarkov@google.com>
- Also allow using the unchecked entry-point for invocations of generic functions where
there are no bounds or the bounds don't require dynamic checks.
Change-Id: I6ca1ebec777ecf2989c4fb77425d65d542d5adf2
Cq-Include-Trybots: luci.dart.try:vm-kernel-optcounter-threshold-linux-release-x64-try, vm-kernel-precomp-linux-debug-x64-try, vm-kernel-precomp-linux-release-simarm-try, vm-kernel-precomp-linux-release-simarm64-try, vm-kernel-precomp-linux-release-x64-try, vm-kernel-precomp-mac-release-simarm64-try, vm-kernel-precomp-win-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/87181
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
MethodInvocation nodes which have field or getter as interface target
actually correspond to 2 calls: 1) getter; 2) implicit call() on the result
of the getter.
While this was correctly modeled in summaries in TFA, it is not correct
to attribute such MethodInvocation nodes with results of the inference,
as results correspond to an each distinct call. To fix this, Call
statements in summaries are created without attaching them to a
corresponding kernel AST node.
Change-Id: I3ea28ed85550192f8b592a926cac0eae23810811
Reviewed-on: https://dart-review.googlesource.com/c/88424
Commit-Queue: Martin Kustermann <kustermann@google.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
A field/function annotated with this pragma must be guaranteed to not
return `null` at runtime.
Make use of this non-nullable annotation in the VM's type propagator.
Annotates the "_TypedListView._typedData" field to ensure the VM knows it
returns a non-nullable _TypedListView.
Furthermore annotates methods on the integer implementation. Those particular
methods are recognized methods with a "dynamic" return type. This caused
the type propagator to use CompileType::Dynamic() as result type. Since a
previous CL started to only utilize the annotated type if it is better than
"dynamic" more integer operations got handled in-line, though with null-checks.
Annotating those methods to return non-null improves the in-line handling of
integer operations.
This improves dart-aot
On arm7hf:
SHA256: +5%, SHA: +6%, JsonObjectRoundTrip: +7%, ...
On arm8:
SHA1: +28%, MD5: +25%, SHA256: +15%, TypedData.Int16ListViewBench: +18.5%, StringInterpolation: +18%, ...
Issue https://github.com/dart-lang/sdk/issues/31954
Issue https://github.com/dart-lang/sdk/issues/35154
Change-Id: Ia4263a37241a36c9dc35e8a48893297effa6f4b2
Reviewed-on: https://dart-review.googlesource.com/c/84421
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Martin Kustermann