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>
This adds in a version of the IL deserializer that doesn't actually do
any deserialization yet.
However, it adds in a couple of compile passes that passes the FlowGraph
for compiled functions through the serializer and deserializer. If the
deserialization step succeeds, then the FlowGraph stored in the
CompilerPassState is replaced with the new FlowGraph for the rest of the
compiler.
Also change the default zone handling in the FlowGraphSerializer to use
the zone for the current thread, instead of the zone stored in the
FlowGraph, so that it is appropriately affected by StackZone uses.
Bug: https://github.com/dart-lang/sdk/issues/36882
Change-Id: I8fa1c7af434f724ccec45ddb73263f84730af5b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/113184
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Aart Bik <ajcbik@google.com>
* Adds non-static final field printing for `Instance`s
* Adds specialized printing for `Closure`s (tearoffs).
* Instances of `Mint` and `Type` can also appear in constant
pools, so handle both in ObjectToSExp.
* DartValueToSExp is a wrapper method for ObjectToSExp that
also checks to see if the value is defined in the constant
pool. If it is, the object is serialized as a reference to
that definition.
* Reworks the `tmp_*_` fields used for non-reentrant cases
to be per function to make it easier to understand how they
interact. (Only cross-function tmp field that remains is
`tmp_string_`, since its contents are always immediately
converted to a C string and then no longer needed.)
Bug: https://github.com/dart-lang/sdk/issues/36882
Change-Id: Ibad4bc2497dd1f580d1daa536c4a267818981c14
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/111425
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Martin Kustermann