Three types of fixes:
1. Remove redundant const_cast
2. Remove const_cast by adding const when appropiate.
3. Remove const_cast by removing const (e.g. places where we call free with it)
For now I only fixed places where the fix is local enough - i.e. does not require
changed a large amount of code.
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org/1526123002 .
Don't perform LICM / or load elimination of static fields in precompiled
code since they may not be initialized and we don't record an explicit
dependency between the initialization and the load of a static field.
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org/1497783002 .
Minimize the number of dependencies of compiler-related files.
This is needed to remove whole .cc/.h files from a compiler-less VM binary which
can be used for running precompiled code.
* removed dependencies of object.cc on flow_graph_compiler.h and flow_graph_builder.h
* removed unnecessary includes from object.h
BUG=
R=srdjan@google.com
Review URL: https://codereview.chromium.org/1411873005 .
Reserve first element in the Function's ic_data_array to hold the edge
counter array.
Until now we had a one-element array per edge counter. This reduces memory
used by edge counters.
This CL allows to optimize code without having to have the unoptimized
code present.
Also, save space in Instruction by making place_id_ and lifetime_position_
a union. place_id_ is exclusively needed by Load/StoreOptimizer,
lifetime_position by the FlowGraphAllocator.
BUG=
R=asiva@google.com
Review URL: https://codereview.chromium.org//1343383003 .
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 .
- Rename accessors of class Field to make it more apparent as to what is being accessed (static field values or instance field offsets
- Use precompiled initializer state (Used only during precompilation) to also store saved initial value of static fields (Used only during application snapshot generation)
BUG=
R=hausner@google.com, rmacnak@google.com
Review URL: https://codereview.chromium.org//1289643005 .
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 .
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 .
- Complete revamp of isolate-specific flags.
- Associate flags with the isolate on creation.
- Dart_CreateIsolate and associate callback do take an
extra flags argument.
- Make sure to clear IC data array when clearing code.
BUG=23578
Review URL: https://codereview.chromium.org//1162033005
It can occur that we don't have exact type information at UnboxUint32 instructions,
but range information concludes that the instruction can't deoptimize. In this case,
we can assume the input must be a smi or mint if the range fits into mint range.
The generated coe for this case was missing on x64 and arm64. It was already added
for ia32, ARM and MIPS (see https://codereview.chromium.org//770303002)
The optimized instruction of the Int32x4 constructor was incorrectly using uint32 as
input representation, instead of int32.
R=iposva@google.com, vegorov@google.com
Review URL: https://codereview.chromium.org//1148943004
Refactor all remaning cases where the current zone is used through new(Isolate*) and remove this interface.
Removing this interface is needed to move towards multiple threads per isolate, and also makes the caller more aware of the scope of the zone used, reducing the risk of use-after-free.
Make the current thread and the stack zone created around native/runtime entries directly available in their body, saving an indirection (and optimized away if unused).
R=iposva@google.com
Review URL: https://codereview.chromium.org//982873004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@44541 260f80e4-7a28-3924-810f-c04153c831b5
The isolate was being passed around, even though only its current zone was used.
Pass that zone directly instead, giving two benefits:
1. helps prepare for the upcoming Isolate/Thread split, where "new(isolate)" must go, and
2. saves a pointer indirection at the allocation sites.
Review URL: https://codereview.chromium.org//855533002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@42935 260f80e4-7a28-3924-810f-c04153c831b5
In addition to tracking input and output ranges in the IC-stubs with a Smi fastpath (SmiAdd and SmiSub, currently) this CL also introduces two IC stubs that have no fast-path by still track ranges and update the range feedback.
We are able to distinguish between the following ranges (encoding of the lattice is shown in the parens):
- u-smi (0000)
- smi (0001)
- uint31 (0010)
- int32 (0011)
- uint32 (0100)
- int64 (1xxx) and (x1x1)
BUG=
R=fschneider@google.com, srdjan@google.com, zra@google.com
Review URL: https://codereview.chromium.org//735543003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@42370 260f80e4-7a28-3924-810f-c04153c831b5
We regressed this logic in r41736 when we started to checking whether current UnboxInt32 can deoptimize, instead of whether it is truncating or not. This was too aggressive.
Additionally fix CanDeoptimize for UnboxInt32([tr], BoxInt64()). It was always returning true because CompileType is not smart enough to encode that Boxing returns either Smi or Mint, which is enough to guarantee that truncating UnboxInt32 won't deoptimize.
R=fschneider@google.com, fscheider@google.com
BUG=
Review URL: https://codereview.chromium.org//798933002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@42319 260f80e4-7a28-3924-810f-c04153c831b5
John McCutchan