| commit | 0bcb0c934ddabd8851090d553c70ec9403b6c108 | [log] [tgz] |
|---|---|---|
| author | Daco Harkes <dacoharkes@google.com> | Tue Mar 26 17:14:13 2024 +0000 |
| committer | Daco Harkes <dacoharkes@google.com> | Tue Mar 26 17:14:13 2024 +0000 |
| tree | 4c4fc55eef348e333c11845dbee010fa9e64e9d4 | |
| parent | 8df8de82b38fae8e9ae1c310fef4f8b735649fd4 [diff] |
[vm/ffi] Add `_Compound` `_offsetInBytes` field This CL changes compounds (structs, unions, and arrays) to be backed by a TypedDataBase and an int offset. Before this CL, the compounds where only backed by a TypedDataBase. This leads to the following issues: 1. Access to nested structs required code for allocating new typed data views or pointers, which the optimizer then had to prevent from being allocated after inlining. 2. Runtime branching on whether the TypedDataBase was a Pointer or TypedData increased code size and prevented inlining. https://github.com/dart-lang/sdk/issues/54892 This could not be properly optimized if in AOT both typed data and pointer were flowing into the same compound. 3. Constructing TypedData views required calculating the length of the view. After this CL, accessing nested compounds will lead to accesses on the original TypedDataBase with an extra offset. This removes the polymorphism on TypedData vs Pointer, because the final int/float/Pointer accesses in nested compounds operate on TypedDataBase. Also, it simplifies creating an `offsetBy` accessor, because it will no longer have to be polymorphic in typed data vs pointer, nor will it have to calculate the length of the field. Implementation details: * The changes in the CFE and patch files are straightforward. * VM: Struct-by-value returns (or callback params) are initialized with an offsetInBytes of 0. * VM: Struct-by-value arguments (and callback return) need to read out the offsetInBytes. Before this CL we were passing in the TypedData as tagged value. With this CL we are passing the TypedData as tagged value and the offset as unboxed int, from 1 IL input to 2 IL inputs. (The alternative would have been to take the compound as a tagged value, but that would have prevented optimizations from not allocating the compound object in the optimizer. The FfiCallInstr is updated to have two definitions for the case where we were passing in the TypedData previously. The NativeReturnInstr is refactored to be able to take two inputs instead of 1. (Note that we don't have VariadicInstr only VariadicDefinition in the code base. So the instruction is _not_ implemented as variadic, rather as having a fixed length of 2.) * dart2wasm does no longer support nested compounds due to the compound implementation only storing a pointer address. https://github.com/dart-lang/sdk/issues/55083 Intending to land this after https://dart-review.googlesource.com/c/sdk/+/353101. TEST=test/ffi CoreLibraryReviewExempt: VM and WASM-only implementation change. Closes: https://github.com/dart-lang/sdk/issues/54892 Bug: https://github.com/dart-lang/sdk/issues/44589 Change-Id: I8749e21094bf8fa2d5ff1e48b6b002c375232eb5 Cq-Include-Trybots: dart-internal/g3.dart-internal.try:g3-cbuild-try Cq-Include-Trybots: dart/try:vm-aot-android-release-arm64c-try,vm-aot-android-release-arm_x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-optimization-level-linux-release-x64-try,vm-aot-win-debug-arm64-try,vm-aot-win-debug-x64-try,vm-aot-win-debug-x64c-try,vm-appjit-linux-debug-x64-try,vm-asan-linux-release-x64-try,vm-checked-mac-release-arm64-try,vm-eager-optimization-linux-release-ia32-try,vm-eager-optimization-linux-release-x64-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try,vm-ffi-qemu-linux-release-arm-try,vm-ffi-qemu-linux-release-riscv64-try,vm-fuchsia-release-x64-try,vm-linux-debug-ia32-try,vm-linux-debug-x64-try,vm-linux-debug-x64c-try,vm-mac-debug-arm64-try,vm-mac-debug-x64-try,vm-msan-linux-release-x64-try,vm-reload-linux-debug-x64-try,vm-reload-rollback-linux-debug-x64-try,vm-ubsan-linux-release-x64-try,vm-win-debug-arm64-try,vm-win-debug-x64-try,vm-win-debug-x64c-try,vm-win-release-ia32-try Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354226 Reviewed-by: Tess Strickland <sstrickl@google.com>
Dart is:
Approachable: Develop with a strongly typed programming language that is consistent, concise, and offers modern language features like null safety and patterns.
Portable: Compile to ARM, x64, or RISC-V machine code for mobile, desktop, and backend. Compile to JavaScript or WebAssembly for the web.
Productive: Make changes iteratively: use hot reload to see the result instantly in your running app. Diagnose app issues using DevTools.
Dart's flexible compiler technology lets you run Dart code in different ways, depending on your target platform and goals:
Dart Native: For programs targeting devices (mobile, desktop, server, and more), Dart Native includes both a Dart VM with JIT (just-in-time) compilation and an AOT (ahead-of-time) compiler for producing machine code.
Dart Web: For programs targeting the web, Dart Web includes both a development time compiler (dartdevc) and a production time compiler (dart2js).
Dart is free and open source.
See LICENSE and PATENT_GRANT.
Visit dart.dev to learn more about the language, tools, and to find codelabs.
Browse pub.dev for more packages and libraries contributed by the community and the Dart team.
Our API reference documentation is published at api.dart.dev, based on the stable release. (We also publish docs from our beta and dev channels, as well as from the primary development branch).
If you want to build Dart yourself, here is a guide to getting the source, preparing your machine to build the SDK, and building.
There are more documents on our wiki.
The easiest way to contribute to Dart is to file issues.
You can also contribute patches, as described in Contributing.