This fixes build errors and crashes when building simarm64 on Windows:
1. __int128 is not supported by Visual Studio. Use Multiply128 instead on Windows.
2. UL is 32-bit - replace with ULL when doing 64-bit math.
R=zra@google.com
Review-Url: https://codereview.chromium.org/2628043006 .
The call sequence is very similar to a classic IC call, except the guarded class and the target are loaded indirectly from the constant pool instead of as immediates. In the monomorphic case, we call directly to the expected target with a class check in the callee. In the unlinked, polymorphic and megamorphic cases, we call a stub; these case are now call-through instead of call-and-return.
Every code, except stubs involved in switchable calls, includes the class check sequence at the beginning. So we now distinguish between a checked and an unchecked entry point. Generated code except the switchable call continues to use the unchecked entry point.
PC offsets are calculated relative to the beginning of the instruction stream, rather than either entry point.
BUG=
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2226893002 .
index table
- Do not try to figure out if the passed in handle is a temporary scoped
handle, instead have all the callers create a ZoneHandle
Compilation of the ESS initialization code in GreenTea reduces from 2.56secs to .497 secs
R=fschneider@google.com
Review URL: https://codereview.chromium.org/1846063002 .
Independently patchable entries are not required for debugging because breakpoints are only added to unoptimized code, nor for deopt because deopt patches the instruction stream and not the object pool.
Future work: Reduce the static call table from (pc offset, function, code) triples to (pc offset, function or allocation stub) pairs.
precompiled dart2js arm 20747140 -> 20674954 (-0.34%)
R=fschneider@google.com
Review URL: https://codereview.chromium.org/1713853003 .
- Defer deoptimization from optimizing compiler to code installation in mutator thread.
- Defer registration of field and leaf class dependency until code is installed in mutator thread.
- Cleanup.
BUG=
R=asiva@google.com
Review URL: https://codereview.chromium.org/1433243003 .
Instead of calling code object directly, call indirectly and
pass the code object in a register. The object pool is then loaded from
the code object. This is another preparation step for making generated code
relocatable.
All non-ia32 platforms:
No entry patching.
ARM:
PC marker (now code object) moves to the same place as on x64 (below saved PP, above saved FP).
R9 is now used as PP, R10 as CODE_REG.
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org//1192103004 .
Remove unused branch/call macro instructions from the assembler.
Setup a frame and pool pointer when invoking leaf runtime functions (in the
deoptimzation stub and store-buffer update stub).
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org//1314883002 .
This makes the code in the code generator independent from how stubs
are actually called (i.e. directly embedding the target address, or
indirectly by loading the target address from the code object).
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org//1270803003 .
Cache a pointer to the isolate's Heap in the Thread object
and use it in generated code for allocation.
Change generated allocation code to load allocation-top and
end via THR (THR->heap.top). This is slightly slower than
embedding the address, but faster than loading it
via the Isolate (THR->isolate->heap.top)
BUG=
R=koda@google.com
Review URL: https://codereview.chromium.org//1263513002 .
to all code emitting routines that may access the pool).
Improve code loading immediates on arm64 (do not read from the pool if 1 or 2
immediate instructions will do).
R=zra@google.com
Review URL: https://codereview.chromium.org//1264543002 .
This allows to make the last explicitly named stubs shared between isolates.
When sharing code stubs, we can't do patching at their entry anymore.
Therefore, I had to remove patching support of the array allocation stub.
Is this a functionality we want to keep?
The change is mostly performance-neutral because optimized code has an inlined fast
path for array allocation and only uses the stub for the slow-case.
The only isolate-specific stubs left are object allocation stubs which are
associated with their Class are per-isolate.
Since this CL removes any isolate-specific stubs from StubCode, it becomes AllStatic.
BUG=
R=koda@google.com
Review URL: https://codereview.chromium.org//1247783002 .
Make context allocation stub shared between isolates.
The fast-path used in optimized code still has isolate-specific
addresses inlined for performance reasons.
Common functions are moved into class_table.h/.cc.
This is a preparation for adding an isolate-independent version of the
allocation code and allocation tracking code.
BUG=
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org//1241863002 .
This CL also lifts the restriction that the object pool can't be used
in VM isolate code on x64 and arm64.
Stubs that perform allocation can't be shared yet, because the inline allocation
code is not yet isolate-independent. This will be added in a separate CL.
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org//1229283002 .
- Track whether class allocation should be traced in existing ClassHeapStats structure.
- Emit compare and branch at top of ::TryAllocate
These changes appear to be performance neutral.
An alternative approach is to deoptimize all code that inlined allocations for a specific class. I do not think this is a good approach because we will spoil the water- allocations that aren't occurring in the (optimized steady state) running program will appear in the allocation profile. This will make the data much less actionable bordering on misleading. The approach used in this CL will guarantee the allocation profile aligns with the actual running program.
R=regis@google.com, srdjan@google.com
Review URL: https://codereview.chromium.org//1213013002 .
They can be loaded via the THR register.
In particular, do this for null, true, false, and the entry point of the UpdateStoreBufferStub.
This will help supporting precompilation and reduce memory usage from constant pools (assuming there are more constant pools than threads).
R=srdjan@google.com
Review URL: https://codereview.chromium.org//1225933002.
The CallToRuntime stub is not needed as a fixed entry anymore since
all stubs set up their own object pool.
The UpdateStoreBuffer stub is still needed because intrinsics don't set
up a normal frame. Changing that would also allow removing this entry.
BUG=
R=srdjan@google.com
Review URL: https://codereview.chromium.org//1215143002.
Also, set up a stub frame with object pool loaded in all stubs on those
platforms. This is a preparation step to making code relocatable.
ia32 is not affected because there is no object pool.
BUG=
R=srdjan@google.com
Review URL: https://codereview.chromium.org//1189573004.
Florian Schneider