This makes the DeoptimizeAll function O(n) instead of O(n^2) where n in the number of optimized functions.
Before this change, DeoptimizeAll iterated over the optimized function list and called DeoptimizingVisitor for each function. The visitor iterated over the optimized function list again to remove the functions that share the same optimized code.
This change partitions the optimized function list into one or more lists of related functions in one pass over the optimized function list.
R=mstarzinger@chromium.org
Review URL: https://chromiumcodereview.appspot.com/11547015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13226 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Making the code size predictable is hard, and to make things even more
complicated, the start of a function can contain various stuff like calls to a
profiling hook, receiver adjustment or dynamic frame alignment. Instead of
tackling all these problems separately, we now simply record the offset where
patching should happen later in the Code object itself.
Review URL: https://codereview.chromium.org/11316218
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13081 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Modules now have their own local scope, represented by their own context.
Module instance objects have an accessor for every export that forwards
access to the respective slot from the module's context. (Exports that are
modules themselves, however, are simple data properties.)
All modules have a _hosting_ scope/context, which (currently) is the
(innermost) enclosing global scope. To deal with recursion, nested modules
are hosted by the same scope as global ones.
For every (global or nested) module literal, the hosting context has an
internal slot that points directly to the respective module context. This
enables quick access to (statically resolved) module members by 2-dimensional
access through the hosting context. For example,
module A {
let x;
module B { let y; }
}
module C { let z; }
allocates contexts as follows:
[header| .A | .B | .C | A | C ] (global)
| | |
| | +-- [header| z ] (module)
| |
| +------- [header| y ] (module)
|
+------------ [header| x | B ] (module)
Here, .A, .B, .C are the internal slots pointing to the hosted module
contexts, whereas A, B, C hold the actual instance objects (note that every
module context also points to the respective instance object through its
extension slot in the header).
To deal with arbitrary recursion and aliases between modules,
they are created and initialized in several stages. Each stage applies to
all modules in the hosting global scope, including nested ones.
1. Allocate: for each module _literal_, allocate the module contexts and
respective instance object and wire them up. This happens in the
PushModuleContext runtime function, as generated by AllocateModules
(invoked by VisitDeclarations in the hosting scope).
2. Bind: for each module _declaration_ (i.e. literals as well as aliases),
assign the respective instance object to respective local variables. This
happens in VisitModuleDeclaration, and uses the instance objects created
in the previous stage.
For each module _literal_, this phase also constructs a module descriptor
for the next stage. This happens in VisitModuleLiteral.
3. Populate: invoke the DeclareModules runtime function to populate each
_instance_ object with accessors for it exports. This is generated by
DeclareModules (invoked by VisitDeclarations in the hosting scope again),
and uses the descriptors generated in the previous stage.
4. Initialize: execute the module bodies (and other code) in sequence. This
happens by the separate statements generated for module bodies. To reenter
the module scopes properly, the parser inserted ModuleStatements.
R=mstarzinger@chromium.org,svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/11093074
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13033 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When code objects in the heap for FUNCTIONs and OPTIMIZED_FUNCTIONs are marked by the GC, their prologue is patched with a call to a stub that removes the patch. This allows the collector to quickly identify code objects that haven't been executed since the last full collection (they are the ones that sill contain the patch). The functionality is currently disabled, but can be activated by specifying the "--age-code".
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/10837037
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12898 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This fixes a corner case when the instance prototype of a function is
changed while inobject slack tracking is still in progress. This caused
the intial map to be unrelated for functions with the same shared info
and hence the shared construct stub is no longer generic enough to work
for all those functions.
R=danno@chromium.org
BUG=chromium:157019
TEST=mjsunit/regress/regress-crbug-157019
Review URL: https://codereview.chromium.org/11293059
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12896 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Previously Crankshaft emitted a generic load for these, now we emit a load of a
named field, guarded by a proto chain check.
LCheckPrototypeMaps now returns the holder, which is for free, because it
already had to check its map as the last step, anyway. This is in sync with what
StubCompiler::CheckPrototype does.
Review URL: https://codereview.chromium.org/11338030
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12847 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This fixes the following Clang warnings:
../../v8/src/ia32/assembler-ia32.cc:1504:24: warning: comparison of constant 16 with expression of type 'v8::internal::Condition' is always true [-Wtautological-constant-out-of-range-compare]
ASSERT(0 <= cc && cc < 16);
~~~~~~~~~~~~~~~~~~~~~^~~~~
../../v8/src/ia32/assembler-ia32.cc:1536:27: warning: comparison of constant 16 with expression of type 'v8::internal::Condition' is always true [-Wtautological-constant-out-of-range-compare]
ASSERT((0 <= cc) && (cc < 16));
~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
BUG=crbug.com/151927
Review URL: https://chromiumcodereview.appspot.com/11225030
Patch from Hans Wennborg <hans@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12792 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The change removes one unused multiply and reschedules
the shift, multiply and jump instructions to reduce
stall. Experiment shows it improve about 20% performance
on x64 for exponetials from about 100 to 2000.
Review URL: https://chromiumcodereview.appspot.com/10939013
Patch from Xi Qian <xi.qian@intel.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12535 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
With this CL we clearly distinguish two different views on Lithium
instructions: For register allocation, the actual instruction/operand
is irrelevant, so it has only an iterator/indexed view on the
instruction operands. All other places, most importantly code
generation, use named getters for the operands now, making it easy to
see where each one is used.
Review URL: https://codereview.chromium.org/10919261
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12510 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL adds multiple things:
Transition arrays do not directly point at their descriptor array anymore, but rather do so via an indirect pointer (a JSGlobalPropertyCell).
An ownership bit is added to maps indicating whether it owns its own descriptor array or not.
Maps owning a descriptor array can pass on ownership if a transition from that map is generated; but only if the descriptor array stays exactly the same; or if a descriptor is added.
Maps that don't have ownership get ownership back if their direct child to which ownership was passed is cleared in ClearNonLiveTransitions.
To detect which descriptors in an array are valid, each map knows its own NumberOfOwnDescriptors. Since the descriptors are sorted in order of addition, if we search and find a descriptor with index bigger than this number, it is not valid for the given map.
We currently still build up an enumeration cache (although this may disappear). The enumeration cache is always built for the entire descriptor array, even if not all descriptors are owned by the map. Once a descriptor array has an enumeration cache for a given map; this invariant will always be true, even if the descriptor array was extended. The extended array will inherit the enumeration cache from the smaller descriptor array. If a map with more descriptors needs an enumeration cache, it's EnumLength will still be set to invalid, so it will have to recompute the enumeration cache. This new cache will also be valid for smaller maps since they have their own enumlength; and use this to loop over the cache. If the EnumLength is still invalid, but there is already a cache present that is big enough; we just initialize the EnumLength field for the map.
When we apply ClearNonLiveTransitions and descriptor ownership is passed back to a parent map, the descriptor array is trimmed in-place and resorted. At the same time, the enumeration cache is trimmed in-place.
Only transition arrays contain descriptor arrays. If we transition to a map and pass ownership of the descriptor array along, the child map will not store the descriptor array it owns. Rather its parent will keep the pointer. So for every leaf-map, we find the descriptor array by following the back pointer, reading out the transition array, and fetching the descriptor array from the JSGlobalPropertyCell. If a map has a transition array, we fetch it from there. If a map has undefined as its back-pointer and has no transition array; it is considered to have an empty descriptor array.
When we modify properties, we cannot share the descriptor array. To accommodate this, the child map will get its own transition array; even if there are not necessarily any transitions leaving from the child map. This is necessary since it's the only way to store its own descriptor array.
Review URL: https://chromiumcodereview.appspot.com/10909007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12492 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This fixes materialization of arguments objects for strict mode functions during
deoptimization. We materialize arguments from the stack area where optimized
code pushes the arguments when entering the inlined environment. For adapted
invocations we use the arguments adaptor frame for materialization.
R=svenpanne@chromium.org
BUG=v8:2261
TEST=mjsunit/regress/regress-2261,mjsunit/compiler/inline-arguments
Review URL: https://chromiumcodereview.appspot.com/10908194
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12489 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This implies that the return value of native getters is checked. The nice part
is that one can even see the name of the property in question in the abort
output when the check failed.
Under some circumstances even the return value of interceptors gets checked, but
I'm not 100% sure about this, because the interceptor code is basically tuned to
death.
The change seems to have very low overhead, so it might be feasible to keep this
check enabled unconditionally.
Review URL: https://chromiumcodereview.appspot.com/10918071
Patch from Sven Panne <svenpanne@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12446 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
xmm0 is not saved across runtime call on x64 because MacroAssembler::EnterExitFrameEpilogue preserves only allocatable XMM registers unlike on ia32 where it preserves all registers.
Cleanup handling of shifts: SHR can deoptimize only when its a shift by 0, all other shift never deoptimize.
Fix type inference for i-to-t change instruction. On X64 this ensures that write-barrier is generated correctly.
R=danno@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10868032
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12373 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Safe operations are those that either do not observe unsignedness or have special support for uint32 values:
- all binary bitwise operations: they perform ToInt32 on inputs;
- >> and << shifts: they perform ToInt32 on left hand side and ToUint32 on right hand side;
- >>> shift: it performs ToUint32 on both inputs;
- stores to integer external arrays (not pixel, float or double ones): these stores are "bitwise";
- HChange: special support added for conversions of uint32 values to double and tagged values;
- HSimulate: special support added for deoptimization with uint32 values in registers and stack slots;
- HPhi: phis that have only safe uses and only uint32 operands are uint32 themselves.
BUG=v8:2097
TEST=test/mjsunit/compiler/uint32.js
Review URL: https://chromiumcodereview.appspot.com/10778029
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12367 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Highlights of this CL:
* Introduced a new opcode in the deoptimizer for a setter stub frame.
* Added a global setter stub for returning after deoptimizing a setter.
* We do not need special deopt support for getters, although the getter stub creates an internal frame. The normal machinery works just right for this case, although we generate a stack that can never occur during normal fullcode execution. If this hurts us one day, we can parameterize and reuse the setter deopt machinery.
Review URL: https://chromiumcodereview.appspot.com/10855098
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12328 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in anticipation of the upcoming lexical global scope.
Mostly automatised as:
for FILE in `egrep -ril "global[ _]?context" src test/cctest`
do
echo $FILE
sed "s/Global context/Native context/g" <$FILE >$FILE.0
sed "s/global context/native context/g" <$FILE.0 >$FILE.1
sed "s/global_context/native_context/g" <$FILE.1 >$FILE.2
sed "s/GLOBAL_CONTEXT/NATIVE_CONTEXT/g" <$FILE.2 >$FILE.3
sed "s/GlobalContext/NativeContext/g" <$FILE.3 >$FILE
rm $FILE.[0-9]
done
R=mstarzinger@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10832342
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12325 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This fixes the positive lookup performed by these LoadICs, to use the
holder instead of the receiver to perfrom the lookup on. It also extends
this improvement to KeyedLoadICs. And it fixes a bug introduced for the
JavaScript getter case of a LoadIC.
R=erik.corry@gmail.com
BUG=chromium:142088
TEST=cctest/test-api/Regress142088,cctest/test-api/Regress137002b
Review URL: https://chromiumcodereview.appspot.com/10828303
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12311 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Now a map points to a transition array which contains the descriptor array. The descriptor array is now immutable. The next step is to share the descriptor array with all back-pointed maps as long as there is a single line of extension. Maps that require a descriptor array but don't need transitions will still need a pseudo-empty transition array to contain the descriptor array.
Review URL: https://chromiumcodereview.appspot.com/10816005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12298 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently only simple setter calls are handled (i.e. no calls in count
operations or compound assignments), and deoptimization in the setter is not
handled at all. Because of the latter, we temporarily hide this feature behind
the --inline-accessors flag, just like inlining getters.
We now use an enum everywhere we depend on the handling of a return value,
passing around several boolean would be more confusing.
Made VisitReturnStatement and the final parts of TryInline more similar, so
matching them visually is a bit easier now.
Simplified the signature of AddLeaveInlined, the target of the HGoto can simply
be retrieved from the function state.
Review URL: https://chromiumcodereview.appspot.com/10836133
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12286 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
mksnapshot or a VM that is booted from a snapshot. --debug-code
can still have an effect on stub and optimized code and it still
works on the full code generator when running without snapshots.
The deoptimizer generates full-code-generator code and relies on it having
the same layout as last time. This means that the code the full code
generator makes for the snapshot should be the same as the code it makes
later. This change makes the full code generator create more consistent
code between mksnapshot time and run time.
This is a bug fix and a step towards making the snapshot code more robust.
Review URL: https://chromiumcodereview.appspot.com/10834085
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12239 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The deoptimizer generates full-code-generator code and relies on it having
the same layout as last time. This means that the code the full code
generator makes for the snapshot should be the same as the code it makes
later. This change makes the full code generator create more consistent
code between mksnapshot time and run time.
This is a bug fix and a step towards making the snapshot code more robust.
Review URL: https://chromiumcodereview.appspot.com/10824084
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12233 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently only simple getter calls are handled (i.e. no calls in count
operations or compound assignments), and deoptimization in the getter is not
handled at all. Because of the latter, we temporarily hide this feature behind a
new flag --inline-accessors, which is false by default.
Review URL: https://chromiumcodereview.appspot.com/10828066
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12223 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The LastAdded points to the descriptor that was last added to the array. From the descriptor we can deduce the NextEnumerationIndex. This allows us to quickly find the property that we are transitioning to, which is necessary for transition-intensive code, eg JSON parsing.
Review URL: https://chromiumcodereview.appspot.com/10695120
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12042 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In this design maps contain descriptor arrays, which in turn can contain transition arrays. If transitions are needed when no descriptor array is present, a descriptor array without real descriptors is inserted just so it can point at the transition array.
The transition array does not contain details about the field it transitions to. In order to weed out transitions to FIELDs from CONSTANT_FUNCTION (what used to be MAP_TRANSITION vs CONSTANT_TRANSITION), the transition needs to be followed and the details need to be looked up in the target map. CALLBACKS transitions are still easy to recognize since the transition targets are stored as an AccessorPair containing the maps, rather than the maps directly.
Currently AccessorPairs containing a transition and an accessor are shared between the descriptor array and the transition array. This simplifies lookup since we only have to look in one of both arrays. This will change in subsequent revisions, when descriptor arrays will become shared between multiple maps, since transitions cannot be shared.
Review URL: https://chromiumcodereview.appspot.com/10697015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11994 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Ensure that IsFound() is only used when not in combination with other
checks. To do so, the default type is NONEXISTENT rather than NORMAL;
and NotFound() also resets the type to NONEXISTENT.
- Use test methods rather than .type() == A_PROPERTY_TYPE.
Review URL: https://chromiumcodereview.appspot.com/10626004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11899 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Only handles when x is int32 and y is int32 constant.
BUG=v8:2038
Currently implemented by imul (not fpmul).
x86 and x64 algorithm differs a bit.
x86 implementation is kind of cumbersome, but I couldn't think of better ways.
Review URL: https://chromiumcodereview.appspot.com/10382033
Patch from Zheng Liu <zheng.z.liu@intel.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11887 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The CompilationInfo record now saves a Zone, and the compiler pipeline
allocates memory from the Zone in the CompilationInfo. Before
compiling a function, we create a Zone on the stack and save a pointer
to that Zone to the CompilationInfo; which then gets picked up and
allocated from.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10534139
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11877 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Removes 6 out of 8 of our remaining unintentional failures on test262.
Also fixes treatment of inherited setters added after the fact.
Specifically:
- In the runtime, when looking for setter callbacks in the prototype chain,
also look for read-only properties. If one is found, reject (exception in
strict mode). If a proxy is found, invoke proper trap.
Note: this folds in the CanPut function from the spec and avoids an extra
lookup over the prototype chain.
- In generated code for stores, insert a test for the maps from the prototype
chain, but only up to the object where the property already exists (which
may be the object itself).
In Hydrogen, if the found property is read-only or not cacheable (e.g. a
proxy), bail out; in a stub, generate an unconditional miss (to get an
exception in strict mode).
- Add test cases and adapt existing test expectations.
R=mstarzinger@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10388047
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11694 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When an array index (in an array access) is a simple "expression + constant", just embed the constant in the array access operation so that the full index expression is (potentially) no longer used and its live range can be much shorter.
This is effective in conjunction with array bounds check removal (otherwise the index is anyway used in the check).
Review URL: https://chromiumcodereview.appspot.com/10382055
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11596 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Until now we always recorded two deoptimization environments for instructions
that are marked as calls. We actually don't need two for all LIR
instructions except one (LInstanceOfKnownGlobal) where there is a lazy
deoptimization point in deferred code.
This change remove on of them and uses one virtual function instead
to make LInstanceOfKnownGlobal work as before.
Additionally, this change removes an unused predicate save_doubles_ from LIR
instructions and removes some helper functions that are used only in one place.
Review URL: https://chromiumcodereview.appspot.com/10035021
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11454 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Constructs the (generally cyclic) graph of module instance objects
and populates their exports. Any exports other than nested modules
are currently set to 'undefined' (but already present as properties).
Details:
- Added new type JSModule for instance objects: a JSObject carrying a context.
- Statically allocate instance objects for all module literals (in parser 8-}).
- Extend interfaces to record and unify concrete instance objects,
and to support iteration over members.
- Introduce new runtime function for pushing module contexts.
- Generate code for allocating, initializing, and setting module contexts,
and for populating instance objects from module literals.
Currently, all non-module exports are still initialized with 'undefined'.
- Module aliases are resolved statically, so no special code is required.
- Make sure that code containing module constructs is never optimized
(macrofy AST node construction flag setting while we're at it).
- Add test case checking linkage.
Baseline: http://codereview.chromium.org/9722043/R=svenpanne@chromium.org,mstarzinger@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9844002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11336 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Do proper dispatch on declaration type instead of mingling together
different code generation paths. Once we add more declaration forms,
this is more scalable.
In separate steps, I'd like to (1) clean up the logic for DeclareGlobal,
and (2) try to reduce the special handling of the name function var if
possible.
R=fschneider@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9704054
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11331 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Some GWT compiled code results in array access that has a heap number (e.g. -0)
as an index. Until now this would result in a generic IC.
For example:
a[-0] === a[0] or
a[0.25 * 4] === a[1]
This change detects heap numbers that are representable as a smi
and converts them. As a result we can still use the fast keyed monomorphic
ICs. Optimized code already handles keyed access with a double-key efficiently.
As a result the frame rate on the reported benchmark improves by roughly 2x.
BUG=v8:1388,v8:1295
Review URL: https://chromiumcodereview.appspot.com/9837109
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11282 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
regexp can match by using a Boyer-Moore-like table. This is done by identifying
non-greedy non-capturing loops in the nodes that eat any character one at a time.
For example in the middle of the regexp /foo[\s\S]*?bar/ we find such a loop.
There is also such a loop implicitly inserted at the start of any non-anchored
regexp.
When we have found such a loop we look ahead in the nodes to find the set of
characters that can come at given distances. For example for the regexp
/.?foo/ we know that there are at least 3 characters ahead of us, and the sets
of characters that can occur are [any, [f, o], [o]]. We find a range in the
lookahead info where the set of characters is reasonably constrained. In our
example this is from index 1 to 2 (0 is not constrained). We can now look 3
characters ahead and if we don't find one of [f, o] (the union of [f, o] and
[o]) then we can skip forwards by the range size (in this case 2).
For Unicode input strings we do the same, but modulo 128.
We also look at the first string fed to the regexp and use that to get a hint
of the character frequencies in the inputs. This affects the assessment of
whether the set of characters is 'reasonably constrained'.
We still have the old lookahead mechanism, which uses a wide load of multiple
characters followed by a mask and compare to determine whether a match is
possible at this point.
Review URL: http://codereview.chromium.org/9965010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11204 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Lithium translation rebuilds hydrogen environments from scratch so we have to ensure that arguments object is correctly bound on function entry otherwise deoptimization will not materialize it.
This fix was implemented as part of r11109 and then reverted.
R=danno@chromium.org
BUG=v8:2045
TEST=test/mjsunit/regress/regress-2045.js
Review URL: https://chromiumcodereview.appspot.com/9963008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11194 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Marking aligned frames with a marker can produce false positives since
an optimized frame spill slot may be mistakenly seen as a marker value.
It also breaks the debugger reproducably: Tested when enabling alignment
for all functions and running the debugger unit tests.
BUG=v8:2009
TEST=no crashes in EarleyBoyer
Review URL: https://chromiumcodereview.appspot.com/9703110
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11075 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
To do this, we collect all accessor properties in a first pass and emit code for
defining those properties afterwards in a second pass.
As a finger exercise, the table used for collecting accessors has a (subset of
an) STL-like iterator interface, including STL-like names and operators.
Although C++ is quite verbose here (as usual, but partly this is caused by our
current slightly clumsy classes/templates), things work out quite nicely and it
cleans up some confusion, e.g. a table entry is not an iterator etc.
Everything compiles into very efficient code, e.g. the loop condition 'it !=
accessor_table.end()' compiles into a single 'testl' instruction on ia32.
+1 for using standard APIs!
Review URL: https://chromiumcodereview.appspot.com/9691040
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11051 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change includes two CLs by pliard@chromium.org:
1. http://codereview.chromium.org/9447052/ (Add CallOnce() and simple LazyInstance implementation):
Note that this implementation of LazyInstance does not handle global destructors (i.e. the lazy instances are never deleted).
This CL was initially reviewed on codereview.appspot.com:
http://codereview.appspot.com/5687064/
2. http://codereview.chromium.org/9455088/ (Remove static initializers in v8):
This CL depends on CL 9447052 (adding CallOnce and LazyInstance).
It is based on a patch sent by Digit.
With this patch applied, we have only one static initializer left (in atomicops_internals_x86_gcc.cc). This static initializer populates a structure used by x86 atomic operations. It seems that we can hardly remove it. If possible, it will be removed in a next CL.
This CL also modifies the presubmit script to check the number of static initializers.
BUG=v8:1859
Review URL: https://chromiumcodereview.appspot.com/9666052
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Previously, there were 1 or 2 calls to the runtime when accessors were changed
or set. This doesn't really work well with property attributes, leading to some
hacks and complicates things even further when trying to share maps in presence
of accessors. Therefore, the runtime entry now takes the full triple (getter,
setter, attributes), where the getter and/or the setter can be null in case they
shouldn't be changed.
For now, we do basically the same on the native side as we did before on the
JavaScript side, but this will change in future CLs, the current CL is already
large enough.
Note that object literals with a getter and a setter for the same property still
do 2 calls, but this is a little bit more tricky to fix and will be handled in a
separate CL.
Review URL: https://chromiumcodereview.appspot.com/9616016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10956 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The old code used a separate HToInt32 instruction which had a wrong register
constraint for the input register which caused wrong result when the stored value
is used after a typed array store. (UseRegister instead of UseTempRegister) when no
SSE3 is available.
This change fixes it by replacing HToInt32 with the corresponding HChange
instruction which has correct register contraints.
TEST=mjsunit/compiler/regress-toint32.js
Review URL: https://chromiumcodereview.appspot.com/9565007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10891 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Only JSObject enumerables with enum cache (fast case properties, no interceptors, no enumerable properties on the prototype) are supported.
HLoadKeyedGeneric with keys produced by for-in enumeration are recognized and rewritten into direct property load by index. For this enum-cache was extended to store property indices in a separate array (see handles.cc).
New hydrogen instructions:
- HForInPrepareMap: checks for-in fast case preconditions and returns map that contains enum-cache;
- HForInCacheArray: extracts enum-cache array from the map;
- HCheckMapValue: map check with HValue map instead of immediate;
- HLoadFieldByIndex: load fast property by it's index, positive indexes denote in-object properties, negative - out of object properties;
Changed hydrogen instructions:
- HLoadKeyedFastElement: added hole check suppression for loads from internal FixedArrays that are knows to have no holes inside.
R=fschneider@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9425045
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10794 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This extends the current support for nested object literals we already
have in Crankshaft, to also support nested array literals and mixed
nested literals containing arrays and objects. All three types are
generated by the unified HFastLiteral instruction.
All previous upper bounds on nested literal graphs remain unchanged,
keeping the size of generated code in check.
The main intention is to boost performance of two-dimensional array
literals containing constant elements (aka. matrices).
R=danno@chromium.org
TEST=mjsunit/compiler/literals-optimized
Review URL: https://chromiumcodereview.appspot.com/9403018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10734 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change enables optimization of top-level and eval-code. For this to work, it adds
support for declaring global variables in optimized code.
At the same time it disables the eager generation of deoptimization support data
in the full code generator (originally introduced in
r10040). This speeds up initial compilation and saves
memory for functions that won't be optimized. It requires
recompiling the function with deoptimization
support when we decide to optimize it.
Review URL: https://chromiumcodereview.appspot.com/9187005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10700 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
1. Instead of checking upfront and estimating a limit for the number, we
now are able to stop register allocation and bailout when we don't
have enough virtual registers.
2. GCed some out-dated flags from flag-definition.h
3. Simplified the interface from the Lithium builder to the
register allocator in lithium-*.cc: For uses and definitions, we
just record the virtual register number given by the Hydrogen value id.
For temporaries, we request a new virtual register from the allocator.
For fixed temps, we don't need to do anything.
4. Increased number of deoptimization entries to 16K. Eventually we
probably want to make this array grow dynamically.
Review URL: https://chromiumcodereview.appspot.com/9325019
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10597 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Yak shaving for map sharing with accessor properties contd.: When CALLBACKS can
have map transitions, simply looking at the property type is not sufficient
anymore to decide if a property is there or not. One has to look at the actual
contents of the descriptor entry then, but this breaks down sometimes when the
lookup is being done with a NULL holder. Luckily enough, we can oftren replace
IsProperty by the simpler IsFound, because we inspect the type immediately
afterwards, anyway.
Review URL: https://chromiumcodereview.appspot.com/9280007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10474 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Loosen the requirement for Map equivalency on several map checks, including checks up the prototype chain, that are not sensitive to ElementsKinds. These selected map checks should also match against FAST_DOUBLE_ELEMENT and FAST_ELEMENT transitions of the original map. This specifically helps all variants of transitioned JSArrays to still efficiently call builtins like push, pop and sort.
BUG=none
TEST=none
Committed: http://code.google.com/p/v8/source/detail?r=10331
Review URL: http://codereview.chromium.org/9015020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10356 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Loosen the requirement for Map equivalency on several map checks, including checks up the prototype chain, that are not sensitive to ElementsKinds. These selected map checks should also match against FAST_DOUBLE_ELEMENT and FAST_ELEMENT transitions of the original map. This specifically helps all variants of transitioned JSArrays to still efficiently call builtins like push, pop and sort.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/9015020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10331 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
CPU-eating DOS attacks against node.js servers. Based on code from
Bert Belder. This version only solves the issue for those that compile
V8 themselves or those that do not use snapshots. A snapshot-based
precompiled V8 will still have predictable string hash codes.
Review URL: http://codereview.chromium.org/9086006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10330 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This introduces an additional check into the StoreIC_ArrayLength builtin
checking that the array still has fast properties. Redifinitions of the
length property that would cause it's type or attributes to change, will
switch to slow properties, thereby invalidating said optimization.
R=svenpanne@chromium.org
BUG=v8:1756
TEST=test262
Review URL: http://codereview.chromium.org/8895025
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10254 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL adds support for loading from and storing to context slots
belonging to harmony let or const bound variables. Checks for the
hole value are performed and the function is deoptimized if they fail.
The full-codegen generated code will take care of properly throwing
a reference error in these cases.
TEST=mjsunit/harmony/block-let-crankshaft.js
Review URL: http://codereview.chromium.org/8820015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10220 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Now with arm and x64 support. Additionally, added default unreachable case to switch statement in CompareIC::TargetState to make win and mac compilers happy.
Reviewer guide:
This is an exact copy of 10216 except:
src/arm/*
src/x64/*
src/ic.cc (added default case to swith in CompareIC::TargetState)
Review URL: http://codereview.chromium.org/8872060
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10219 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This includes specialcasing the generation when we know that the maps
of the two objects are the same. In addition, a new specialized
compare ic known objects cache is created.
The reason for the cache is that we need to have access to the stub
code from the roots; if we do not, the GC will collect the stub. In
this specialized case we use the map pointer as key in the cache, and
we always do a lookup before generating code. Actually hitting
something in the cache will happen very rarely, but we could
potentially overwrite an existing stub, which again will lead to the
GC collecting this old stub (even if it is referenced from other code
objects)
Review URL: http://codereview.chromium.org/8520006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10216 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
So far we had two types of stack checks: one used for function entries
and one used at loop back edges which uses a deferred code object to
avoid spilling of registers in the loop.
After refactoring lazy deoptimization the first stack check can also
use deferred code. This change removes the first type of stack check
instruction in Crankshaft and uses a deferred stack check in all
places.
Review URL: http://codereview.chromium.org/8775002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10118 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This shaves 416+ KB, just under 1% off the size of the debug d8 executable
on Linux (mostly because the CheckHelper functions for assertions were
getting separate copies for each compilation unit). The difference in
release builds is negligible---a size reduction of 0.1%.
Also, change namespace-level 'static const' variables to remove the static
storage class as it's the default.
R=danno@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8680013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10083 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL introduces a third mode next to the non-strict
(henceforth called 'classic mode') and 'strict mode'
which is called 'extended mode' as in the current
ES.next specification drafts. The extended mode is based on
the 'strict mode' and adds new functionality to it. This
means that most of the semantics of these two modes
coincide.
The 'extended mode' is entered instead of the 'strict mode'
during parsing when using the 'strict mode' directive
"use strict" and when the the harmony-scoping flag is
active. This should be changed once it is fully specified how the 'extended mode' is entered.
This change introduces a new 3 valued enum LanguageMode
(see globals.h) corresponding to the modes which is mostly
used by the frontend code. This includes the following
components:
* (Pre)Parser
* Compiler
* SharedFunctionInfo, Scope and ScopeInfo
* runtime functions: StoreContextSlot,
ResolvePossiblyDirectEval, InitializeVarGlobal,
DeclareGlobals
The old enum StrictModeFlag is still used in the backend
when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes:
* SetProperty runtime function, Delete builtin
* StoreIC and KeyedStoreIC
* StubCache
Review URL: http://codereview.chromium.org/8417035
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This generates optimized code for deep-copying of nested object literal
boilerplates which are statically known. Most of the boilerplates have
already been generated at crankshaft time, so this optimization should
kick in for virtually every object literal. Only nested object literal
graphs up to a certain depth and containing up to a certain total number
of properties are considered for this optimization. This will prevent
explosion of code size due to large object literals (e.g. eval on JSON).
Improves splay performance because object literals are created often.
R=fschneider@chromium.org
Review URL: http://codereview.chromium.org/8640001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10061 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
