Previously, before switching to compact encoding of bytecode
instructions, we had to align bytecode instructions by 4.
Since that time sections of bytecode binary were aligned.
However, this alignment doesn't work well in AOT mode if dill file
contains both bytecode and AST, as other metadata (such as obfuscation
prohibitions) may precede bytecode metadata and may make the whole
bytecode binary misaligned.
This results in incorrect calculation of section offsets,
failed assertion
assert(writer.offset - start == section.offset);
and VM may fail to load bytecode binary with error
bytecode_reader.cc: 1368: error: unreachable code
In order to fix these problems, extra alignment of bytecode
sections is removed.
Change-Id: Iaa3b7c46999615aaa446781a7018db409261ead8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123686
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Scripts loaded from kernel AST always have non-null line_starts
(line_starts could be zero-length if there are no line numbers).
Scripts loaded from bytecode can have null line_starts if line
numbers are not present, so Script::GetTokenLineUsingLineStarts is
fixed to handle this correctly.
Fixes https://github.com/dart-lang/sdk/issues/39168
Change-Id: I84b5e7ef804b07b3d35420eba5c17246264d8baa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123482
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Classes declared in bytecode are loaded lazily. So, in case there is
a mix of bytecode and AST kernel files, it's OK if AST constant
references a class which is not loaded yet, if that class is declared in
bytecode.
Change-Id: I6e28da7c6a97d19d88e16d6cd8abd0e9b61df388
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/122847
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Aart Bik <ajcbik@google.com>
BaseDirectChainedHashMap<KeyValueTrait, B, Allocator>::Iterator::Next()
was first checking if array_index_ is larger than the size of map's array,
and only then it was looking at remaining entries in the collision list.
So, when there is a collision in the last bucket, array_index_ was bumped
and the first entry in the list was returned. After that, Next() returned
NULL, skipping remaining entries in the collision list.
This caused incorrect stack state management in BytecodeFlowGraphBuilder
and BytecodeFlowGraphBuilder::DropUnusedValuesFromStack() was removing
too many entries from the stack, which caused crash in
BytecodeFlowGraphBuilder::BuildStoreIndexedTOS().
Issue: https://github.com/dart-lang/sdk/issues/38979
Change-Id: Ie073ca7014da5b04999b7984d508984b4c9743b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/122176
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Loading of appended snapshots used to try read the executable itself
via arg[0] which holds the "path" to the executable.
However, when the executable is being invoked via PATH the "path"
can be just the name of the executable with no actual path.
This would cause the file reading to fail to find the file and
therefore fail to read.
This in turn caused standalone executables to fail to run when invoked
via PATH.
Bug: https://github.com/dart-lang/sdk/issues/38912
Change-Id: I08501661441db90ce6cff96a9337a5770ec3524d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/121853
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
When creating a place for an indirect indexed access into typed data
list (one which uses LoadUntagged to load base pointer), don't consider
this place to be constant indexed even if index itself is a constant.
Base pointer returned by LoadUntagged can be pointing into some other
typed array - meaning that the actual index is C plus an unknown
offset.
Fixes https://github.com/dart-lang/sdk/issues/38467
Change-Id: I1fb50c2d265537d2b6dd185c10ddc74dc06147b2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/121123
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
While emitting code for a ParallelMove on ARM32, the TMP register was
being used as a dest/src. When the stack slot offset is large,
StoreToOffset creates a new base in TMP in order to use a smaller
offset. Since the ParallelMove implementation was hardcoding TMP as the
dest/src register, the assert that the register != TMP failed with large
offsets. Now we instead perform a check to see if the offset will fit to
determine whether or not we can use TMP or if we need to fall back and
use LR as our temporary (we can do this since we're in the middle of a
ParallelMove).
Fixes https://github.com/dart-lang/sdk/issues/38654
Change-Id: I4d8cc8b54f6090d86992aabb8ff44d088bc02d3e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119584
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
The code from these precompiled constructors is thrown away,
and if we are adding constants to the LLVM constant pool, then
we may add constants that will not actually appear in the final
program which may cause issues for tree shaking.
If these constructors are actually used, then they will be
recompiled normally.
In addition, we also do not add unreferenced constants to the
constant pool. That is, these constant definitions will not have
an `llvm_index` value in their serialized form when the LLVM
constant pool is populated.
Bug: https://github.com/dart-lang/sdk/issues/38661
Change-Id: I2a3702fd3f174504a5f01458064306cd687d7949
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119339
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Consider the following situation:
class A { foo() {...} }
class B extends A { foo() {...} }
During AOT compilation (in case FLAG_lazy_dispatchers == false)
Resolver::ResolveDynamicAnyArgs was not looking for possible methods
when getter is requested. As a result, if method extractor A.get:foo
has been created, but B.get:foo hasn't, then lookup for B.get:foo
incorrectly returns A.get:foo (instead of null).
Similar situation was previously fixed for a particular call site of
ResolveForReceiverClass (which uses ResolveDynamicAnyArgs):
https://dart-review.googlesource.com/c/sdk/+/30520
However, there are more calls to ResolveForReceiverClass in the compiler
where its incorrect result may be used.
Change-Id: I4ebd6b91157cc048b94e5a5ce182c42dc808f4f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118260
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This test assumes `gen_snapshot` is available in the build folder where
the test gets run from. Though simarm_x64 is special in that only
test.py knows about the location of the right `gen_snapshot`.
Therefore we skip this test on simarm_x64 (which is '$builder_tag ==
crossword").
Change-Id: I677c781a970dec358f593c4504051ac515d48d0f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/116961
Reviewed-by: Martin Kustermann <kustermann@google.com>
Fix an AOT call specialization that broke this relationship.
When printing environments in the FlowGraphPrinter, also print the
underlying value for any PushArguments.
Change-Id: I39803b7d995abac720702ea4b9d6a78fcbc45d4c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115981
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The Dart runtime will be able to load snapshot blobs appended at the end of
itself.
This is a step on the way to a self-contained native executable.
Tested:
$ dart2aot hello_world.dart hello_world.aot
$ <Some steps to hand-craft appended binary ..>
$ dartaotruntime_plus_hello_world.bin
Hello, world!
python tools/test.py -n dartk-linux-debug-x64 vm/dart/run_appended_aot_snapshot_test
Change-Id: I79d5500c4e2668da31cf1d27145296d17470e04c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/112382
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
At this point, we do get some successful deserializations (of
methods that are optimized into constant value returns).
Adds support for:
GraphEntry (including constant pool)
FunctionEntry
TargetEntry
Return
Results from compiling hello world program:
* Early round trip
* Contains unhandled instructions: 4180
* Failed during deserialization: 0
* Successful round trip: 0
* Late round trip
* Contains unhandled instructions: 4163
* Failed during deserialization : 0
* Successful round trip: 15
Bug: https://github.com/dart-lang/sdk/issues/36882
Change-Id: I9e0919f6ffbfe059ce0efd55f9a767c1ba805795
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/113325
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Aart Bik <ajcbik@google.com>
Alexander Markov